AI Extensions, 8 novembre : quand partager une connexion MCP entre projets
OpenCode 2.2.6 permet le partage MCP. Comptes, protocole, absence de roots et attente sans limite définissent ses contraintes.
Ouvrir le même serveur MCP dans plusieurs projets peut laisser tourner plusieurs connexions. OpenCode 2.2.6 permet leur partage sur demande. La documentation exige davantage qu'un nom identique et précise que la connexion partagée n'a pas de roots, les racines des répertoires de projet.
Le sujet du jour
OpenCode v2.2.6 a été publié le 6 novembre. La version annonce moins de processus et des démarrages plus rapides grâce au partage MCP, ainsi que de nouvelles options pour les scripts. Sa licence MIT autorise la réutilisation selon ses conditions. Une sortie récente indique une activité de maintenance, sans prouver la sécurité ou l'adéquation. Je n'ai ni installé cette version, ni chronométré son démarrage, ni testé de serveur MCP avec elle.
La configuration part d'une installation existante d'OpenCode, de ses paramètres MCP et, si nécessaire, de l'authentification propre au serveur. Selon la documentation MCP, pool vaut false par défaut.
Les connexions qui peuvent être partagées
Le partage concerne les répertoires d'un même serveur OpenCode et les connexions négociant la révision 2026-07-28 du protocole. Quand pool est activé sans protocol explicite, auto est utilisé. Une réponse avec une ancienne révision ou un réglage legacy conserve une connexion par répertoire.
Pour un serveur distant, URL, en-têtes, paramètres OAuth, compte connecté, protocole et délais doivent correspondre. Les noms peuvent normalement différer, mais les connexions OAuth sont enregistrées par nom : celui-ci doit donc aussi être identique. Pour un serveur local, la commande, l'environnement et le répertoire de travail doivent correspondre.
Le partage local fonctionne entre répertoires de la même machine, pas avec des répertoires dans un workspace. Partager entre projets exige un cwd fixe. Sans cela, le serveur tourne dans chaque dossier de projet et OpenCode émet un avertissement. Changer cwd pour obtenir le partage serait un mauvais compromis si le serveur ne devait voir qu'un seul projet.
Les droits restent à examiner
Une connexion partagée n'a pas de roots. Une demande de saisie d'un outil apparaît dans le répertoire qui l'a appelé. Ces règles ne promettent pas que le serveur applique lui-même une séparation d'accès entre projets. J'examinerais d'abord ses accès aux fichiers et le périmètre du compte.
Deux projets utilisant le même compte très large peuvent satisfaire les règles tout en portant des attentes humaines différentes sur les données autorisées. Le partage ne fournit aucune permission manquante. Je conseille de séparer staging et production et de laisser pool désactivé pour un serveur dépendant des roots ou d'un état mutable propre au projet, jusqu'à vérification. Ce sont des recommandations de déploiement, pas l'annonce d'une faille découverte dans OpenCode.
Ce JSON est volontairement un relevé de décisions non exécutable, pas une configuration OpenCode valide. Il ne contient aucun secret et n'assure aucune isolation.
- Deux répertoires demandent un serveur
- Comparer réglages et protocole négocié
- Partager si admissible ; connexion sans roots
{
"server_role": "public-documentation-search",
"pool_requested": true,
"same_account_scope": "review-required",
"requires_project_roots": "review-required",
"fixed_local_cwd": "not-applicable-to-remote",
"protocol_seen": null,
"approved": false
}
Pour un essai autorisé, choisissez un serveur jetable et des données synthétiques. Comparez pool-off et pool-on dans deux répertoires, puis changez une condition de correspondance. Notez le protocole négocié, le nombre de processus ou de connexions et le répertoire recevant la demande de saisie. Essayez un serveur qui exige des roots. Un appel réussi ne prouve pas l'isolation. Ce test est proposé, pas réalisé pour cet article.
Un script peut désormais attendre sans limite
La même version indique qu'opencode run attend les commandes shell en arrière-plan, sous-agents et tâches d'images lancés par sa demande, puis laisse le modèle traiter leurs résultats avant de sortir. Cette attente n'a pas de limite intégrée. Un serveur de développement ou un processus de surveillance peut maintenir le lancement ouvert jusqu'à interruption. Les notes disent que SIGTERM annule la session et ses tâches d'arrière-plan et termine avec le code 143.
En CI, je définirais un délai externe et le livrable attendu avant le lancement. Une réponse au premier plan ne suffit pas si le fichier dépend encore d'une tâche. run -w crée un nouveau worktree git et ne peut pas être associé à --continue ou --session. --archived masque les sessions scriptées des listes et de la boîte de réception habituelles, rendant les journaux du travail plus importants.
Par où commencer
Un serveur documentaire en lecture seule, avec le même périmètre de compte dans les projets, convient à un petit essai. Un serveur qui dépend des roots exige un test distinct. Le changement d'attente mérite un examen en CI même sans pooling. Les notes de version et les chiffres de popularité ne certifient pas le comportement réel du serveur.