Donne aux agents une machine qu’ils peuvent casser.Garde la tienne.

Pourquoi .git

Git, sur ta machine, exécute ce que désignent le .git/config et les hooks d’un dépôt : core.fsmonitor à chaque git status, les hooks au commit. Ton éditeur et ton prompt lancent git status d’eux-mêmes : une VM capable d’écrire dans .git pourrait lancer des commandes sur ton hôte en quelques secondes, sans que rien n’apparaisse dans git diff.

Chaque .git et .hg des partages est en lecture seule pour la VM, à toute profondeur, et c’est le serveur SFTP intégré à agent-vm, sur ta machine, qui l’impose (le sshfs.readonlyNames de Lima, pas encore intégré en amont : lima-vm/lima#5529). L’agent lit l’historique mais ne peut pas commiter. Les partages sont en reverse-sshfs, plus lent sur beaucoup de fichiers (voir Node.js), et sans le cache de sshfs sur ceux qui sont modifiables, pour que la VM ne réécrive jamais un fichier tel qu’il était avant que tu le changes : AGENT_VM_SSHFS_CACHE=1 échange cela contre de la vitesse.

agent-vm doctor    # où tu en es

# laisser l'agent commiter quand même
agent-vm --unsafe-writable-git claude

Au-delà du nom .git

Le dossier vers lequel pointe un core.hooksPath dans un partage (.husky pour husky) est aussi en lecture seule, comme un lien sur le chemin qui y mène, et de même pour les dépôts de tes volumes modifiables. Un dossier qui contient les fichiers internes de git (HEAD, objects/, refs/, un config) est un dépôt sous n’importe quel nom : régler safe.bareRepository à explicit dans ta config git globale le fait ignorer par git, et celui d’un volume modifiable est en lecture seule par son nom. Une config incluse depuis un partage, une commande ou un hook que git y lance, ou des hooks à la racine d’un partage, ouvrent la même porte.

Avant de démarrer une VM aux partages modifiables, agent-vm s’arrête sur chacun de ceux qu’il trouve, pour demander : Entrée, ou l’absence de terminal, annule. doctor les liste. --unsafe-writable-git (ou AGENT_VM_UNSAFE_WRITABLE_GIT=1 dans ton shell, jamais lu depuis le projet) laisse l’agent commiter et rouvre ce chemin vers ton hôte, avec un avertissement à chaque lancement.

Lima, intégré

agent-vm compile Lima, son serveur SFTP (sshocker et pkg/sftp) et sa pile réseau (gvisor-tap-vsock) depuis leurs sources amont, avec des correctifs assez petits pour être proposés en amont : les noms en lecture seule, des corrections du serveur SFTP (un ajout en fin de fichier qui faisait tomber la VM, des écritures appliquées dans le désordre), l’isolation réseau, la vérification des ports. Chaque VM en marche est servie par un processus agent-vm, qui est l’agent hôte de Lima.

Chaque partage est servi par le serveur SFTP intégré, cantonné à son dossier : agent-vm ne démarre aucune VM dont la config dit autre chose, quoi qui l’ait réglée. Un default.yaml ou override.yaml dans ~/.agent-vm/lima/_config s’ajouterait à la config de chaque VM : agent-vm ne démarre aucune VM tant qu’il y en a un.

Dossiers et fichiers refusés

agent-vm ne partage ni ton dossier personnel, ni /, ni son propre dossier, ni ~/.agent-vm, ni le dossier de ton propre Lima (~/.lima), ni un dossier qui en contient un : cd ~ && agent-vm shell donnerait à la VM tes fichiers de configuration et tes clés SSH. --unsafe-disable-security-prompts lui fait partager son propre dossier, pour travailler sur agent-vm depuis un clone : la VM peut alors modifier l’agent-vm que ta machine lance.

Il ne lit jamais un fichier du projet par son chemin, puisque la VM peut en faire un lien vers n’importe lequel de tes fichiers. Ses propres appels à git dans un projet refusent un dépôt nu et ne lancent ni core.fsmonitor ni pager.

--readonly, en détail

--readonly couvre tous les partages, volumes rw compris : un volume accessible en écriture contenant le projet serait une seconde entrée. Le serveur SFTP intégré l’impose sur ta machine, et agent-vm vérifie la config de chaque VM avant son démarrage, jamais sur la parole de l’invité.

Une VM en marche dans l’autre mode est redémarrée, après confirmation. Refusé, ou sans terminal, la commande échoue : la VM en lecture seule d’une autre session ne repasse jamais en écriture sous elle.

La règle

Tout ce qui, sur ta machine, lit le projet et agit selon ce qu’il y trouve peut exécuter ce que l’agent a écrit. agent-vm ferme les portes de git (voir Protéger .git), mais ne peut pas verrouiller les fichiers que lisent tes autres outils sans empêcher l’agent de travailler.

Donc, sur ta machine, ouvre le projet dans ton éditeur et utilise git dedans ; lance tout le reste dans la VM, avec agent-vm run. Les listes qui suivent sont des exemples, pas un inventaire.

• Rien du tout : ce qui se lance quand tu fais cd dans le dossier, quand ton prompt se redessine, quand ton éditeur l’ouvre. Le cas le plus dangereux.
• Un geste que tu fais de toute façon : git commit lance des hooks rangés dans l’arborescence, docker compose up monte ce que nomme le fichier compose.
• Lancer du code du projet : npm test, make, un build. C’est le code de l’agent : lance-le dans la VM.

Fichiers surveillés

Pour le premier cas, agent-vm surveille les fichiers que ta machine exécute d’elle-même : quand la VM en écrit, crée, renomme ou supprime un, à n’importe quelle profondeur des partages, une fenêtre te demande d’abord. Un oui vaut jusqu’à l’arrêt de la VM ; un non, une minute, après quoi une nouvelle tentative redemande. Là où aucune fenêtre ne peut s’afficher (pas de session graphique), l’écriture est refusée et une notification le dit ; une fenêtre restée sans réponse deux minutes la refuse aussi. AGENT_VM_GUARDED_WRITES=deny les refuse toutes sans demander.

Surveillés par défaut : .envrc (direnv), .vscode/tasks.json, .vscode/settings.json et .vscode/launch.json (VS Code), .pre-commit-config.yaml (pre-commit), lefthook.yml et .lefthook.yml (lefthook), mise.toml et .mise.toml (mise). Les fichiers que l’agent modifie couramment, comme un Makefile ou un package.json, ne le sont pas : ajoute-les dans ~/.agent-vm/guarded, un chemin par ligne, lu au démarrage d’une VM. !chemin retire un fichier par défaut, et *.ext surveille une extension. Sur un hôte Windows, *.library-ms, *.searchConnector-ms, *.lnk, *.url, *.scf et desktop.ini le sont aussi : l’Explorateur envoie ton empreinte NTLM au serveur qu’ils nomment quand il les affiche. Il n’y a pas de fenêtre de confirmation sous Windows : les écritures de la VM sur ces fichiers sont refusées.

# ~/.agent-vm/guarded
Makefile               # demander avant que la VM change un Makefile
.github/workflows/ci.yml
!.vscode/settings.json # plus demandé

Éditeurs et agents

Un fichier suivi modifié apparaît dans git diff, un nouveau comme non suivi ; un fichier dans un chemin ignoré (node_modules, .venv, target/) n’apparaît nulle part.

• VS Code : ouvre les projets agent-vm en mode restreint, et n’approuve pas un dossier parent. Un espace de travail approuvé exécute du code du projet par ses tâches et extensions : eslint.config.js, vite.config.ts, build.rs.
• IDE JetBrains : « Preview in Safe Mode ». Un projet approuvé lance ses scripts Gradle ou Maven à l’import.
• Vim : laisse exrc désactivé. Neovim et Emacs demandent avant d’exécuter la config d’un projet.
• Les agents sur ta machine lancent des commandes depuis les hooks de .claude/settings.json, .mcp.json ou .cursor/ : relis-les, et considère CLAUDE.md et AGENTS.md comme écrits par la VM.

SSH depuis ta machine

Ne branche pas VS Code Remote-SSH ou open-remote-ssh sur une VM d’agent. Ils font tourner un serveur dans la VM, que contrôle root dans la VM, et l’éditeur sur ta machine lui fait confiance. La page de Remote-SSH chez Microsoft le dit : « a compromised remote could use the VS Code Remote connection to execute code on your local machine », et c’est voulu. Des articles publics le montrent ouvrant un terminal sur l’hôte et y lançant des commandes. Cela supprime la frontière que pose agent-vm, ce qui est pire qu’ouvrir le projet en mode restreint. JetBrains Gateway ne se dit pas plus sûr : sa page sur le modèle de sécurité dit que ce que charge le backend arrive sur ta machine sans rien demander, que le backend y ouvre des liens (après confirmation) et décide de la version du client qu’elle télécharge. Pour les serveurs de langage et un débogueur avec les paquets de la VM, utilise agent-vm code.

Pour des scripts, scp ou rsync, agent-vm info affiche l’alias SSH comme ssh_host. Mets ces lignes en haut de ~/.ssh/config : un ForwardAgent yes trouvé avant elles donnerait tes clés SSH à la VM. lima-* couvre aussi les VM de ton propre Lima, si tu en as un. --ssh-port fixe le port pour les outils qui l’enregistrent.

# en haut de ~/.ssh/config
Include ~/.agent-vm/lima/*/ssh.config
Host lima-*
  ForwardAgent no
  ForwardX11 no

agent-vm info | grep ^ssh_host   # l'alias à utiliser
agent-vm --ssh-port 2222 shell   # un port fixe

Shell, commandes, hooks

• direnv ne charge qu’un .envrc que tu as autorisé, et une modification retire l’autorisation ; agent-vm demande aussi avant que la VM en écrive un (Fichiers surveillés).
• mise fait confiance à une config selon son chemin : une VM autorisée à modifier un mise.toml approuvé fait lancer ses hooks à ton shell, et définir son environnement, au cd suivant, variables AGENT_VM_UNSAFE_* d’agent-vm comprises. agent-vm demande avant cette écriture ; mise settings set paranoid true lie aussi la confiance au contenu. Une config sous un autre nom (mise.local.toml, .mise/config.toml) n’est surveillée qu’une fois que tu l’ajoutes.
• npm run, make, ./gradlew, pytest, node_modules/.bin, un .venv activé : chacun lance des fichiers que l’agent peut écrire. Lance-les dans la VM.
• docker compose up sur ta machine peut monter n’importe lequel de tes dossiers dans un conteneur root. Docker tourne dans la VM : sers-t’en là.
• lefthook et pre-commit gardent leurs commandes dans l’arborescence : agent-vm demande avant que la VM change leur config, mais pas les scripts qu’elle nomme. Les hooks de husky appellent des scripts du projet. Relis-les dans le diff, ou commite avec --no-verify.

Gestionnaires de fichiers

• macOS : les fichiers écrits à travers le partage ne portent pas l’attribut de quarantaine, donc Gatekeeper ne vérifie pas un .app, .command ou .pkg laissé là. Ne les ouvre pas depuis le Finder.
• Windows : l’Explorateur peut contacter le serveur nommé dans un .library-ms, .searchConnector-ms, .lnk, .url, .scf ou desktop.ini qu’il affiche, et lui envoyer ton empreinte NTLM (CVE-2025-24054 pour .library-ms, CVE-2025-50154 et CVE-2025-59214 pour .lnk). Des correctifs ont déjà été contournés. agent-vm refuse sous Windows les écritures de la VM sur ces fichiers ; garde Windows à jour, le SMB sortant (TCP 445) bloqué et, si tu peux, NTLM bloqué côté client SMB.
• Linux : Dolphin, sous KDE, lançait des commandes depuis un .desktop d’un dossier qu’il ne faisait qu’afficher (CVE-2019-14744, corrigée dans KDE Frameworks 5.61).

Séquences d’échappement du terminal

Ce qu’affiche la VM arrive tel quel dans ton terminal, et les terminaux réagissent aux séquences d’échappement. agent-vm ne peut pas les filtrer sans casser les interfaces plein écran des agents.

• Presse-papiers : OSC 52 permet à un programme d’écrire dans ton presse-papiers, et, dans certains terminaux, de le lire. N’autorise jamais la lecture, et regarde ce que tu colles dans un shell de l’hôte.
• Réponses tapées à ta place : une séquence envoyée juste avant la sortie peut faire taper le terminal dans ton shell. Certaines ont été de vrais bugs (iTerm2 CVE-2024-38396) : garde ton terminal à jour.
• Fonctions qui agissent sur ta machine : transfert de fichiers et triggers d’iTerm2, contrôle à distance de kitty (laisse-le désactivé), liens dont le texte diffère de la cible.
• Usurpation : la VM peut afficher un faux prompt de l’hôte après une fausse sortie. Vérifie où tu es avant de taper un secret.

Réseau et ports

Une VM atteint Internet, pas ta machine : sa boucle locale (où sont redirigés les ports des autres VM), ses propres adresses et tes réseaux locaux (plages privées, link-local et CGNAT) sont refusés, sur ta machine, par la pile réseau qu’agent-vm fait tourner pour chaque VM. Root dans la VM ne peut pas le lever.

Il n’y a pas de ~/.agent-vm/network par défaut, et il n’en faut pas : sans lui, les VM atteignent tout Internet et rien de ta machine ni de tes réseaux locaux. Écris-en un pour ouvrir des passages, lu au démarrage d’une VM, une ligne chacun : allow une adresse (192.168.1.20), une adresse et un port (192.168.1.20:5432, [fd00::5]:80), un réseau (10.8.0.0/16), ou un service de la boucle locale de ta machine, localhost:PORT (localhost seul ouvre tous les ports), que la VM atteint à 192.168.5.2. Une ligne allow vaut pour TCP et UDP.

Les lignes domain restreignent Internet lui-même : ces domaines et leurs sous-domaines (domain github.com couvre api.github.com ; *.github.com revient au même) deviennent les seuls noms que les VM résolvent, et une adresse n’est joignable qu’une fois donnée par le DNS d’agent-vm pour l’un d’eux. Les lignes allow s’appliquent toujours. Une ligne illisible arrête le démarrage, en la nommant ; doctor vérifie le fichier. AGENT_VM_UNSAFE_OPEN_NETWORK=1 dans ton shell désactive l’isolation.

Chaque port qu’écoute une VM est redirigé vers ton 127.0.0.1, et une notification le signale, sauf 32768-60999 : l’invité les attribue aux programmes qui demandent un port libre quelconque (le port DevTools de Chromium, les serveurs de langage), et ils restent dans la VM. Un port sur lequel écoute un de tes programmes lui est laissé, avec une notification aussi : sous macOS, une VM qui écouterait la première sur 5432 recevrait sinon les connexions, et les mots de passe, destinés à ton Postgres local. Sur un port libre, ce que tu y envoies va à la VM : regarde la notification.

Aucune VM n’atteint plus l’éditeur d’une autre, mais agent-vm code donne toujours à chacune son propre mot de passe, créé dans cette VM, et son propre nom d’hôte, <nom-de-vm>.localhost. Une VM peut servir une page sur un port redirigé et envoyer ton navigateur au nom d’hôte d’une autre VM sur ce port ; les navigateurs rangent les cookies par nom d’hôte et non par port, donc le navigateur lui remet le cookie de cet éditeur. La VM ne peut pas s’en servir contre l’éditeur lui-même, puisque ta boucle locale lui est refusée, mais arrête agent-vm code (Ctrl-C) quand tu ne t’en sers pas. Chrome et Firefox résolvent *.localhost eux-mêmes ; Safari peut ne pas le faire, et 127.0.0.1 dans une fenêtre privée réservée à l’éditeur fait alors la même chose.

# ~/.agent-vm/network
allow localhost:11434       # Ollama sur cette machine, à 192.168.5.2:11434
allow 192.168.1.20:5432     # une base de données du réseau local
allow 10.8.0.0/16           # un VPN

# seulement ceux-là sur Internet, sous-domaines compris
domain github.com
domain npmjs.org