CalypsoCode

CalypsoCode est un lanceur Linux pour agents de code. Il retire un ensemble défini d'identifiants (adresse réseau, identité git, locale et fuseau horaire, config propre de l'agent) de ce que l'agent transmet, et à la sortie il indique ce qu'il a retiré et ce qu'il n'a pas retiré. Je l'ai construit en quelques semaines, en juillet 2026.

Le problème

Savoir si un fournisseur de modèles peut lire votre code dépend du fournisseur choisi. Savoir s'il peut dire que c'était vous qui demandiez est un autre problème, et je n'ai trouvé personne qui le traite. Ma première conception faisait tourner les clés d'API à chaque requête sur un unique circuit Tor partagé. En y réfléchissant, j'ai compris que cela change l'identifiant tout en gardant le réseau constant, ce qui donne au fournisseur la preuve que tous ces comptes sont la même personne. L'identité est l'ensemble des signaux qui relient deux requêtes : tous doivent changer à la même frontière.

Approche : configurer, ne pas réécrire

L'unité est le profil : un fichier par compartiment, qui nomme le réseau, le point d'accès du fournisseur, le modèle, une identité git et le nom de la variable d'environnement contenant la clé, jamais la clé elle-même. Un compartiment, c'est une clé, une config, une identité, et rien ne passe d'un compartiment à l'autre.

Le lanceur n'inspecte ni ne réécrit jamais le trafic. Il contrôle l'environnement de démarrage de l'agent : oniux enferme l'agent dans un espace de noms réseau Tor qui échoue en mode fermé au niveau du noyau, LC_ALL=C et TZ=UTC suppriment locale et fuseau, les variables d'auteur git sont fixées, et XDG_CONFIG_HOME pointe vers le compartiment pour que ma config globale ne soit jamais chargée. Retirer un signal à la source est plus fiable que le nettoyer après coup, et cela ne peut pas corrompre le code.

Mesuré, pas supposé

L'essentiel du travail a consisté à tester le comportement réel de la pile, et le dépôt le consigne en constats numérotés. Plusieurs ont invalidé mon plan : un processus de l'hôte ne peut pas joindre un port ouvert dans l'espace de noms, donc ma conception avec un proxy LiteLLM n'était pas réalisable et je l'ai supprimée. oniux injecte silencieusement ALL_PROXY, ce qui casse le loopback. XDG_CONFIG_HOME seul n'isole pas un agent, car données et état sont ailleurs.

Mon premier test de fuite ne pouvait pas échouer ; je l'ai réécrit pour qu'il s'exécute depuis l'intérieur de l'espace de noms, contre des cibles d'abord confirmées joignables depuis l'hôte. Une vraie session de code sur Tor avec l'agent livré a pris 4 allers-retours, 3,6 s en moyenne, 0 échec. La suite de tests est en scripts shell couvrant la sortie réseau, les fuites, les profils et les reçus, avec un outil de mutation de sécurité, et shellcheck en CI.

Le reçu et l'agent

À la sortie, le lanceur écrit un reçu : sortie Tor, résultat du test de fuite, durée de session, et liste explicite de ce qui n'a pas été retiré. L'agent lancé est un fork rebrandé d'OpenCode, modifié pour ne plus envoyer de User-Agent qui identifie le client.

Limites et suite

Cette session est une tâche, un fournisseur, un jour. La réaction des fournisseurs au trafic Tor sur plusieurs semaines et la latence sur un gros dépôt ne sont pas testées. Tor change de sortie en cours de session (trois en 27 minutes), et savoir s'il faut en fixer une reste une question ouverte. Deux choses ne peuvent pas être retirées : le compte avec lequel on paie, et son style d'écriture. Le code est sous AGPL-3.0 ; je travaille sur la dernière étape de la feuille de route.