Zed + Ollama: der ultraschnelle Editor mit Assistent lokal

#Ollama in Zed konfigurieren

Die offizielle Dokumentation von Zed beschreibt eine Vorgehensweise in vier Schritten: Ollama herunterladen und installieren, ein Modell herunterladen, prüfen, ob der Ollama-Server läuft, und anschließend dieses Modell im Dropdown-Menü von Zed auswählen.

ollama pull mistral
ollama serve

Unter macOS genügt es, die Anwendung Ollama.app zu starten, um den Server zu starten; unter Linux oder aus einer Shell heraus bewirkt der Befehl ollama serve dasselbe. Zed wird von seinem Herausgeber als leistungsstarker Code-Editor für mehrere Nutzer vorgestellt, der von den Schöpfern von Atom und Tree-sitter entwickelt wurde; die neueste stabile Version mit Stand vom 28. September 2026 ist v1.21.0, veröffentlicht am 23. September 2026, und das Repository hatte am selben Tag knapp 91.000 Sterne auf GitHub.

Diese Ollama-Konfiguration unterstützt sämtliche KI-Funktionen von Zed, die auf einem Sprachmodell basieren: das Agent-Panel für Aufgaben über mehrere Dateien hinweg, den Inline-Assistenten (Inline Assistant) für gezielte Änderungen im Editor und die Terminal-Threads, in denen der Agent Befehle vorschlagen kann. Externe Agenten und Terminal-Threads können allerdings eine eigene Konfiguration für ein lokales Modell erfordern, getrennt von der hier beschriebenen Konfiguration für die nativen Funktionen von Zed.

#Automatische Modellerkennung

Zed erkennt automatisch die Modelle, die Ollama bereits heruntergeladen hat, und bietet sie im Auswahlmenü an. Um diese Erkennung zu deaktivieren und die Modelle selbst mit ihren genauen Fähigkeiten aufzulisten, müssen Sie in den Einstellungen auto_discover auf false setzen.

{
  "language_models": {
    "ollama": {
      "api_url": "http://localhost:11434",
      "auto_discover": false,
      "available_models": [
        {
          "name": "qwen2.5-coder",
          "display_name": "qwen 2.5 coder",
          "max_tokens": 32768,
          "supports_tools": true,
          "supports_thinking": true,
          "supports_images": true
        }
      ]
    }
  }
}

Dieser manuelle Modus hat einen praktischen Nutzen: Er ermöglicht es, supports_tools oder max_tokens für ein Modell vorzugeben, das Zed automatisch nicht korrekt einordnen würde, oder in der versionierten Konfigurationsdatei des Projekts zu dokumentieren, welches Modell das Team verwenden soll.

Das Feld supports_tools verdient besondere Aufmerksamkeit: Es teilt Zed mit, ob das Modell im Zed-Agenten Werkzeugdefinitionen empfangen kann (Dateien bearbeiten, Befehle ausführen), statt auf einen einfachen Chat beschränkt zu sein. Ein Ollama-Modell ohne deklarierte Fähigkeit zu Werkzeugaufrufen funktioniert für den Inline-Assistenten oder die Autovervollständigung, aber nicht für Aufgaben über mehrere Dateien hinweg im Agent-Panel.

#Das Kontextfenster mit 4096 Tokens

Zed übermittelt die Kontextlänge über den Parameter num_ctx an Ollama, laut offizieller Dokumentation standardmäßig mit 4096 Tokens. Das ist deutlich weniger als das native Kontextfenster der meisten neueren Modelle (oft 32.000 Tokens oder mehr), und schon eine mittelgroße Datei kann ausreichen, um diese Obergrenze zu überschreiten.

{
  "language_models": {
    "ollama": {
      "context_window": 8192
    }
  }
}

Die Einstellung context_window gilt für alle in Zed konfigurierten Ollama-Modelle. Eine eigene Kontextgröße pro Modell lässt sich über max_tokens in available_models festlegen; deaktivieren Sie dabei auto_discover, damit der Wert berücksichtigt wird.

#llama.cpp und LM Studio als lokale Alternativen

Zed unterstützt llama.cpp genauso wie Ollama, mit automatischer Erkennung der im Router-Modus bereitgestellten Modelle, die durch einen /models/sse-Datenstrom verfeinert wird. Dieser erfordert eine aktuelle Version des llama.cpp-Servers. LM Studio wird ebenfalls über seinen lokalen API-Server unterstützt, der mit lms server start gestartet wird.

#Berechtigungen der Agent-Tools

Seit Version 0.224.0 wird die Genehmigung der Tools des Zed-Agenten über agent.tool_permissions.default eingestellt; vor dieser Version regelte ein einfacher boolescher Wert (agent.always_allow_tool_actions, standardmäßig false) sämtliche Tool-Aktionen. Das neue System ermöglicht Regeln anhand von Regex-Mustern mit drei möglichen Entscheidungen: erlauben, verweigern oder immer eine Bestätigung anfordern.

{
  "agent": {
    "tool_permissions": {
      "default": "allow",
      "tools": {
        "terminal": {
          "default": "confirm",
          "always_allow": [
            { "pattern": "^cargo\\s+(build|test|check)" }
          ],
          "always_confirm": [{ "pattern": "sudo\\s+/" }]
        }
      }
    }
  }
}

Dieses Beispiel aus der offiziellen Dokumentation erlaubt automatisch bestimmte cargo-Befehle im Terminal-Tool, verlangt aber grundsätzlich eine Bestätigung für jeden sudo-Befehl, der das Stammverzeichnis des Systems betrifft — eine nützliche Feinabstufung, wenn das angebundene Modell ein kleines lokales Modell ist, das weniger vorhersehbar ist als ein Cloud-Referenzmodell.

#Die Sandbox: Was sie wirklich schützt

Über deklarative Berechtigungen hinaus bietet Zed eine Sandbox auf Betriebssystemebene für die Tool-Aufrufe seines Agenten. Die Dokumentation beschreibt ihren Geltungsbereich genau: Sie gilt ausschließlich für die Tools terminal und fetch, nicht für Zed selbst, Sprachserver, Erweiterungen, Aufgaben oder gewöhnliche Terminal-Tabs.

Terminal-Tool

Die Sandbox beschränkt Schreibzugriffe auf den Datenträger und ausgehende Netzwerkzugriffe der vom Agenten ausgeführten Befehle; die Git-Metadaten sind geschützt.

fetch-Tool

Die Sandbox schränkt ein, welche Hosts der Agent tatsächlich kontaktieren kann.

Voraussetzungen für Linux

Eine ausführbare bwrap-Binärdatei ohne gesetztes setuid-Bit muss im PATH vorhanden sein.

Voraussetzungen für Windows

WSL muss verfügbar sein; die Dokumentation weist darauf hin, dass die Sandbox dort schwächer ist als unter Linux oder macOS und möglicherweise nicht alle Versuche blockiert, aus ihr auszubrechen.

Diesen begrenzten Geltungsbereich (nur Terminal und fetch) sollten Sie berücksichtigen, bevor Sie einem kleinen, weniger vorhersehbaren lokalen Modell sensible Aufgaben anvertrauen: Dateiänderungen über edit_file oder write_file unterliegen den deklarativen Berechtigungen und Agentenprofilen, nicht der Isolation auf Systemebene durch die Sandbox. Eine menschliche Überprüfung bleibt bei diesen Aktionen daher sinnvoll, auch wenn die Sandbox für die übrigen Aktionen aktiv ist.

#MCP-Server in Zed

Über Ollama als Modellanbieter hinaus nutzt Zed das Model Context Protocol, um mit externen Kontextservern zu interagieren: Datenbanken, Ticket-Management-Systeme, Unternehmensdokumentation. Die offizielle Dokumentation erklärt, dass Zed die Funktionen Werkzeuge und Prompts des MCP unterstützt, was dem Agenten zusätzliche Fähigkeiten verleiht, die jenseits der integrierten Werkzeuge (Datei-Editierung, Terminal) liegen.

Um sicherzustellen, dass ein bestimmter MCP-Server tatsächlich verwendet wird, statt mit den integrierten Werkzeugen von Zed zu konkurrieren, zeigt die Dokumentation ein spezielles Agentenprofil (am Beispiel des Servers container-use). Dieses deaktiviert die integrierten Werkzeuge und aktiviert nur die Werkzeuge des gewählten MCP-Servers, wobei enable_all_context_servers in der Profilkonfiguration auf false gesetzt wird.

{
  "enable_all_context_servers": false,
  "context_servers": {
    "container-use": {
      "tools": {
        "environment_create": true,
        "environment_add_service": true,
        "environment_update": true,
        "environment_run_cmd": true
      }
    }
  }
}

Diese fein abgestufte Steuerung nach Profil ergänzt das oben beschriebene Berechtigungssystem für einzelne Tools: Bei einem lokalen Ollama-Modell, das weniger vorhersehbar ist als ein Cloud-Referenzmodell, verringert die Beschränkung der Tools, die dem Agenten tatsächlich zur Verfügung stehen – ob von einem MCP-Server oder aus den nativen Funktionen von Zed –, die Möglichkeiten für Fehler, noch bevor es um Berechtigungen und die Sandbox geht.

• MCP: Was ist das? Das Model Context Protocol erklärt
• MCP-Server an Ollama anschließen

#Prädiktive Bearbeitung (Zeta) auch lokal

Zed bietet eine vom Chat-Agenten getrennte Funktion: die prädiktive Bearbeitung, die während Ihrer Eingabe die nächste Änderung vorschlägt und mit einem Druck auf Tab bestätigt wird. Der Standardanbieter ist Zeta, ein von Zed selbst entwickeltes Open-Source-Modell – getrennt von den Konversationsmodellen, die für das Agent-Panel oder den Online-Assistenten konfiguriert sind.

Damit diese Funktion vollständig lokal bleibt, lässt sich laut offizieller Dokumentation ein eigener Ollama-Anbieter für die Vorhersage von Bearbeitungen konfigurieren, mit dafür vorgesehenen Modellvarianten (insbesondere zeta2), statt das bereits für den Agenten konfigurierte Chatmodell wiederzuverwenden – die beiden Einstellungen sind in Zed unabhängig voneinander. Ein kleineres Modell, das darauf zugeschnitten ist, jeweils eine einzelne Änderung vorherzusagen, statt ein Gespräch über mehrere Runden zu führen, antwortet bei dieser konkreten Aufgabe in der Regel schneller als ein allgemeines Chatmodell. Das zählt hier mehr als die reine Fähigkeit zum Schlussfolgern: Entscheidend ist die beim Tippen wahrgenommene Latenz, lange bevor es auf die inhaltliche Vielfalt der Antworten ankommt.

#Ollama auf einem entfernten Server

Wenn Ollama auf einem anderen Rechner läuft oder einen Schlüssel erfordert (wie bei Ollama Turbo, der gehosteten Version), wird der Schlüssel in der Anbieteroberfläche oder über die Variable OLLAMA_API_KEY eingegeben. Die API-URL muss auf den entfernten Endpunkt statt auf localhost zeigen.

Dieses Szenario mit einem entfernten Server bietet einem Team einen konkreten Vorteil: Ein einziger Ollama-Server, der für ein Modell angemessener Größe ausgelegt ist, kann mehrere Zed-Arbeitsplätze bedienen, die mit derselben API-URL konfiguriert sind. So muss nicht jeder Entwickler das Modell auf seinem eigenen Rechner ausführen und erneut laden. Das Kontextfenster und die deklarierten Fähigkeiten (supports_tools, supports_thinking) müssen dann nur einmal eingestellt werden, und zwar in der gemeinsamen Projektkonfiguration statt in den persönlichen Einstellungen jedes Einzelnen.

• Lokaler Copilot mit Cline: KI-Agent in VS Code (Ollama)
• Cline + Ollama: 100 % lokaler Code-Agent in VS Code
• Continue.dev von Cursor übernommen: zu Cline im lokalen Betrieb wechseln
• Quelle: offizielle Dokumentation der lokalen Modelle in Zed
• Quelle: offizielle Dokumentation der Agenten-Sandbox
• Quelle: offizielle Dokumentation zu Werkzeugrechten