Transmission des variables d’environnement
Le daemon s’exécute en tant que processus en arrière-plan et dispose généralement d’un environnement réduit. Votre terminal possède l’environnement complet configuré par votre profil shell. Il existe deux façons pour les variables d’environnement d’atteindre les sous-processus shell générés par l’agent.
transfert zerocode (automatique)
Lorsque zerocode se connecte, il capture son propre environnement de processus et l’envoie au daemon dans le cadre de la poignée de main initialize. Le daemon stocke cet instantané dans TuiRegistry, indexé par le tui_id unique de zerocode. Lorsque vous ouvrez une nouvelle session de chat (session/new), le daemon recherche l’instantané enregistré par la connexion appelante elle-même, jamais celui désigné par la requête, et le clone dans le ShellTool de l’agent. Ce clone est ensuite superposé à la base d’environnement sûre (safe-env) pour chaque sous-processus shell que l’agent lance :
cmd.env_clear()
→ Layer 1: SAFE_ENV_VARS + shell_env_passthrough (from daemon process)
→ Layer 2: zerocode's env snapshot (wins on conflict)
les variables zerocode l’emportent en cas de conflit : vos sockets PATH, HOME et d’identifiants ont la priorité sur ce que le démon a hérité. Aucune configuration requise.
Voilà pourquoi SSH_AUTH_SOCK fonctionne lorsque vous exécutez zerocode depuis un terminal sur lequel un ssh-agent est actif, même si le démon a été démarré en tant que service sans agent :
sh
# Terminal a SSH_AUTH_SOCK défini par ssh-agent ou un jeton matériel (YubiKey, etc.)
echo $SSH_AUTH_SOCK
# /run/user/1000/gnupg/S.gpg-agent.ssh
# Le démon a été démarré en tant que service systemd, sans SSH_AUTH_SOCK dans son environnement.
# zerocode forwards its env at connect time, so any shell command the agent
# runs (git push, ssh, gpg-sign) récupère SSH_AUTH_SOCK depuis votre terminal.
zerocode envoie son environnement complet à chaque connexion, mais le daemon ne conserve ce instantané que là où il est jugé fiable : un principal de niveau opérateur sur une connexion locale (le socket Unix ou le tube nommé Windows), qui correspond au flux IDE local décrit plus haut. Sur une connexion WSS, l’instantané décrit l’hôte du client et non celui du daemon, et un principal de la liste autorisée doté d’un profil de permissions ne doit pas pouvoir choisir ce qui s’exécute sous le compte du daemon. Dans les deux cas, le daemon supprime donc l’instantané à initialize, consigne qu’il l’a fait, et les sous-processus shell de la session ne voient que la couche 1. Utilisez shell_env_passthrough dans le profil de risque pour transmettre des variables précises depuis l’environnement propre au daemon dans ce cas.
Plusieurs clients connectés : pas d’écrasement entre sessions
Chaque instance de zerocode reçoit un tui_id unique (tui_ + 8 caractères hexadécimaux aléatoires). Le registre est une HashMap<tui_id → TuiEntry>, et les entrées sont complètement indépendantes :
TuiRegistry
├── "tui_a1b2c3d4" → { env: { PATH: "/home/alice/…", VIRTUAL_ENV: "…" } }
├── "tui_beef0042" → { env: { PATH: "/home/bob/…" } }
└── "tui_cafe1234" → { env: { PATH: "/opt/pyenv/…" } }
Quand zerocode tui_a1b2c3d4 ouvre une session, seul son instantané d’environnement est cloné et utilisé. Les environnements des autres clients ne sont jamais modifiés. Concrètement :
| Scénario | Résultat |
|---|---|
Deux clients ouverts depuis des shells différents avec des PATH différents | Chaque session dispose de son propre PATH ; aucune n’affecte l’autre |
Le client A a VIRTUAL_ENV défini ; le client B ne l’a pas | Seules les sessions du Client A voient VIRTUAL_ENV |
| Le Client A se déconnecte pendant que la session du Client B est en cours | Le client B n’est pas affecté ; l’env a été cloné à la création de la session |
| Le client B rattache une session que le client A a créée alors que cette session est toujours active | Refusé sauf si les deux clients transmettent exactement le même environnement ; les variables propres à chaque terminal, comme TERM_SESSION_ID, diffèrent généralement, donc démarrez plutôt une nouvelle session |
Le client A se reconnecte avec le même tui_id | L’ancienne entrée est supprimée, une nouvelle entrée avec un environnement à jour est enregistrée ; les sessions déjà en cours conservent leur clone d’origine |
Le dernier point est important : le registre remet à la session un clone, et non une référence. Une fois la session créée, elle possède son propre instantané d’environnement. Les reconnexions ou déconnexions du client d’origine n’ont aucun effet sur les sessions en cours.
Transmission directe du profil de risque (liste d’autorisation explicite)
shell_env_passthrough sur un profil de risque contrôle quelles variables de l’environnement de processus propre au daemon sont transmises aux sous-processus shell. Ceci est utile lorsque vous souhaitez que des variables spécifiques soient disponibles, que zerocode soit connecté ou non, par exemple sur un serveur headless où le daemon lui-même a les variables définies.
Les sous-agents ne peuvent pas étendre cette liste au-delà de ce que la politique parente autorise : l’ajout d’une variable absente de la liste du parent est rejeté comme une escalade de politique.