Zed + Ollama : l'éditeur ultra-rapide avec assistant local

#Configurer Ollama dans Zed

La documentation officielle de Zed décrit une marche à suivre en quatre étapes : télécharger et installer Ollama, tirer un modèle, vérifier que le serveur Ollama tourne, puis sélectionner ce modèle dans le menu déroulant de Zed.

ollama pull mistral
ollama serve

Sur macOS, lancer l'application Ollama.app suffit à démarrer le serveur ; sur Linux ou depuis un shell, la commande ollama serve fait la même chose. Zed est présenté par son éditeur comme un éditeur de code multi-utilisateurs et hautes performances, créé par les auteurs d'Atom et de Tree-sitter ; la dernière version stable au 28 septembre 2026 est v1.21.0, publiée le 23 septembre 2026, et le dépôt comptait près de 91 000 étoiles sur GitHub à la même date.

Cette configuration Ollama sert l'ensemble des fonctionnalités IA de Zed qui s'appuient sur un modèle de langage : le panneau Agent pour des tâches multi-fichiers, l'assistant en ligne (Inline Assistant) pour des modifications ciblées dans l'éditeur, et les threads de terminal qui laissent l'agent proposer des commandes. Les agents externes et les threads de terminal peuvent toutefois exiger leur propre configuration de modèle local, séparée de celle décrite ici pour les fonctionnalités natives de Zed.

#Détection automatique des modèles

Zed détecte automatiquement les modèles qu'Ollama a déjà téléchargés et les propose dans le menu de sélection. Pour désactiver cette détection et lister soi-même les modèles avec leurs capacités précises, il faut passer auto_discover à false dans les réglages.

{
  "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
        }
      ]
    }
  }
}

Ce mode manuel a un intérêt pratique : forcer supports_tools ou max_tokens pour un modèle que Zed ne classerait pas correctement automatiquement, ou documenter dans le fichier de configuration versionné du projet quel modèle l'équipe est censée utiliser.

Le champ supports_tools mérite une attention particulière : c'est lui qui indique à Zed si le modèle peut recevoir des définitions d'outils dans l'agent Zed (édition de fichiers, exécution de commandes) plutôt qu'être cantonné à un simple chat. Un modèle Ollama sans capacité d'appel d'outils déclarée fonctionnera pour l'assistant en ligne ou l'autocomplétion, mais pas pour les tâches multi-fichiers du panneau Agent.

#La fenêtre de contexte à 4096 tokens

Zed transmet la longueur de contexte à Ollama via le paramètre num_ctx, avec 4096 tokens par défaut selon la documentation officielle. C'est nettement inférieur à la fenêtre native de la plupart des modèles récents (souvent 32 000 tokens ou plus), et un fichier de taille moyenne peut suffire à dépasser ce plafond.

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

Ce réglage context_window s'applique à tous les modèles Ollama configurés dans Zed ; un contexte différent par modèle se définit via max_tokens dans available_models, en désactivant auto_discover pour que la valeur soit prise en compte.

#llama.cpp et LM Studio, les alternatives locales

Zed prend en charge llama.cpp au même titre qu'Ollama, avec une découverte automatique des modèles servis en mode routeur, affinée par un flux /models/sse qui exige une version récente du serveur llama.cpp. LM Studio est également supporté via son serveur API local, démarré avec lms server start.

#Permissions des outils de l'agent

Depuis la version 0.224.0, l'approbation des outils de l'agent Zed se règle via agent.tool_permissions.default ; avant cette version, un simple booléen (agent.always_allow_tool_actions, false par défaut) gouvernait l'ensemble. Le nouveau système permet des règles par motif regex, avec trois issues possibles : autoriser, refuser, ou toujours demander confirmation.

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

Cet exemple, tiré de la documentation officielle, autorise automatiquement des commandes cargo précises dans l'outil terminal tout en exigeant systématiquement une confirmation pour toute commande sudo touchant à la racine du système — une granularité utile quand le modèle branché est un petit modèle local moins prévisible qu'un modèle cloud de référence.

#Le bac à sable : ce qu'il protège vraiment

Au-delà des permissions déclaratives, Zed propose un bac à sable au niveau du système d'exploitation pour les appels d'outils de son agent. La documentation est précise sur son périmètre : il s'applique uniquement aux outils terminal et fetch, pas à Zed lui-même, ni aux serveurs de langage, extensions, tâches ou onglets de terminal classiques.

Outil terminal

Le bac à sable restreint les écritures sur le disque et l'accès réseau sortant des commandes lancées par l'agent ; les métadonnées Git sont protégées.

Outil fetch

Le bac à sable restreint les hôtes que l'agent peut effectivement contacter.

Prérequis Linux

Un binaire bwrap exécutable et non setuid doit être présent dans le PATH.

Prérequis Windows

WSL doit être disponible ; la documentation précise que le bac à sable y est plus faible que sous Linux ou macOS et peut ne pas bloquer toutes les tentatives d'évasion.

Ce périmètre limité (terminal et fetch seulement) est important à intégrer avant de confier des tâches sensibles à un petit modèle local moins prévisible : les modifications de fichiers faites via edit_file ou write_file passent par les permissions déclaratives et les profils d'agent, pas par l'isolation système du bac à sable. Une revue humaine reste donc utile sur ces actions, même avec le bac à sable actif sur le reste.

#Ollama sur un serveur distant

Si Ollama tourne sur une autre machine ou exige une clé (cas d'Ollama Turbo, la version hébergée), la clé se saisit dans l'interface du fournisseur ou via la variable OLLAMA_API_KEY, et l'URL de l'API doit pointer vers l'endpoint distant plutôt que vers localhost.

Ce scénario distant a un intérêt concret pour une équipe : un unique serveur Ollama, dimensionné pour un modèle de taille correcte, peut servir plusieurs postes Zed configurés avec la même URL d'API, évitant à chaque développeur de faire tourner et de recharger le modèle sur sa propre machine. La fenêtre de contexte et les capacités déclarées (supports_tools, supports_thinking) restent alors à régler une seule fois, dans la configuration partagée du projet plutôt que dans les réglages personnels de chacun.

• Copilot local avec Cline : agent IA dans VS Code (Ollama)
• Cline + Ollama : agent de code 100 % local dans VS Code
• Continue.dev racheté par Cursor : migrer vers Cline en local
• Source : documentation officielle des modèles locaux dans Zed
• Source : documentation officielle du bac à sable de l'agent
• Source : documentation officielle des permissions d'outils