Construire Nagano
Sept CLI d’agents de code, une seule file d’approbations
Nagano n’inclut aucun modèle. Un daemon local lance la CLI de chaque agent comme un processus supervisé et enregistre chaque approbation qu’elle demande. Comment ça marche, et quels agents demandent.


Nagano est une app macOS pour les CLI d’agents de code. La fenêtre est un client d’un daemon local sur 127.0.0.1:7788, un processus Node embarqué dans l’app. Le daemon ne contient aucune implémentation de harness. Chaque harness est un plugin : un processus séparé qui parle JSON-RPC versionné en NDJSON sur stdio, choisi par le fichier de verrouillage nagano.plugins.json et sondé au démarrage. Une session reçoit un processus.
Sept harness, trois protocoles
Nagano parle à chaque CLI par l’interface propre à cette CLI. Claude Code diffuse du JSON. Codex parle son protocole JSON-RPC app-server. Kimi Code est lancé avec --output-format stream-json. GLM est le Coding Plan de z.ai, qui fait tourner le binaire de Claude Code contre api.z.ai. Grok Build (grok agent stdio) et OpenCode Go (opencode acp) parlent tous deux ACP. Antigravity est le agy --print de Google.
Vous installez chaque CLI vous-même; Nagano n’en embarque aucune. Chacune se connecte de son côté, et Nagano ne transmet aucune clé sauf si vous en configurez une. La santé est un sondage, pas une vérification de version : une poignée de main ACP initialize pour Grok Build et OpenCode Go, les options --help que le plugin passe pour Claude Code et Antigravity, un sondage de compatibilité de protocole pour Kimi Code, l’initialisation propre au serveur d’app pour Codex. Chaque verdict est mis en cache selon le SHA-256 du binaire, les succès seulement, si bien qu’une CLI qui se met à jour est revérifiée automatiquement.
Ce qu’est une interaction
Quand un harness demande une approbation, pose une question ou propose un plan, le daemon enregistre une interaction. GET /v1/interactions?state=pending est la boîte de réception; POST /v1/interactions/{id}/resolve en résout une, avec une vérification de révision qui rejette une réponse périmée. Dans l’app, cette boîte est « Vous attend » sur le tableau de bord, avec une notification, et chaque approbation s’ouvre dans la conversation qui l’a demandée.
Le README liste les règles que le daemon s’impose. Chaque approbation doit offrir Refuser ou Annuler, et toute valeur par défaut de l’interface doit refuser ou annuler. Les choix d’approbation portent des portées explicites, et l’enveloppe d’exécution interdit les autorisations persistantes : « toujours permettre » ne peut pas s’exprimer. Le journal conserve séparément l’option choisie et l’accusé de réception du plugin, et ne présente ni l’un ni l’autre comme la preuve que l’effet a eu lieu. Un plugin doit clore ses interactions non résolues avant de pouvoir terminer le tour. Une interruption arrivée en premier annule les approbations en attente. Après un redémarrage du daemon, une interaction en attente devient uncertain plutôt que d’être résolue à votre place.

Quels agents demandent
Chaque plugin déclare ce qu’il sait faire dans nagano-plugin.json. Cinq déclarent interaction.request.approval : Claude Code, Codex, GLM, Grok Build et OpenCode Go. Codex va plus loin et distingue l’approbation d’une commande de celle d’un changement de fichier. Claude Code et GLM exposent aussi session.setPermissionMode, par quoi le mode de permission d’un projet (ask, full ou plan) atteint la CLI.
Kimi Code et Antigravity ne déclarent aucune capacité d’interaction. Elles s’exécutent sans interaction : il n’y a rien à approuver en cours de tour, et vous obtenez le résultat à la fin. C’est une propriété de ces CLI aujourd’hui, pas un réglage de Nagano.
Le reste de la fenêtre
La vue de conversation diffuse la transcription avec les appels d’outils, les événements de fichiers et une ligne du temps des points de contrôle. Son panneau latéral offre Contexte (la répartition des jetons), Git (le diffstat), Aperçu et En cours. Il n’y a pas d’éditeur de code.
Un projet est un dossier. Une session active tient un répertoire à la fois, sous un bail d’espace de travail dans SQLite; une deuxième tâche sur un répertoire qu’une autre session possède reçoit 409 conflict avant même d’être enregistrée. Les worktrees Git sont la façon de faire tourner des voies parallèles sur un même dépôt, et la fiche Nouvelle tâche propose Même copie, Nouveau worktree et Nouveau worktree en emportant vos changements.
Orchestrer prend une consigne et la répartit en voies entre les harness, par vagues, avec une carte de plan et des voies que vous pouvez arrêter. La même chose existe en ligne de commande : nagano orchestrate --plugin claude,kimi --start --wait.
Limites à connaître
- macOS 15 ou plus récent, Apple silicon seulement.
- Le journal dans
~/.nagano/nagano.sqliteconserve les demandes, la sortie des outils et tout ce qu’un harness imprime, sans caviardage. Le README qualifie le niveau de sécurité actuel de MVP local de confiance. - Le daemon écoute sur votre réseau local pour le jumelage avec d’autres Mac et l’app iPhone, protégé par un code QR. Nagano s’exécute localement, avec un jumelage facultatif sur votre réseau; ce n’est pas « rien ne quitte votre Mac ». Les demandes et le contenu du dépôt vont à chaque fournisseur par la CLI de ce fournisseur.
- Les titres, les jugements d’attention et les aperçus sont produits par des tâches cachées sur votre propre harness, et ils consomment votre quota.
- Aucune analytique ni rapport de plantage n’a été trouvé dans le code source.



