A sandbox is only useful if it actually keeps the agent inside the fence. Claude Code 2.1.216 tightens several gaps that could let a background task, subagent, or resumed session wander outside its assigned directory. This release introduces a new configuration switch, but the more important work is under the hood: smarter handling of Git worktrees, symlinks, and agent restarts. If you run Claude Code locally or in CI, these changes deserve more than a quick skim of the changelog.
The Filesystem Toggle You Should Not Touch Lightly
Version 2.1.216 adds sandbox.filesystem.disabled. When this is set, Claude Code skips its own filesystem isolation while still enforcing the network sandbox. At first glance this sounds like a way to stop permission errors or speed up file operations. It is not. You should only enable this setting if another layer is already protecting your disk.
That means a disposable container that gets deleted after every run, or a dedicated virtual machine with no access to your home directory or production volumes. If you run Claude Code directly on macOS, Windows, or a bare Linux host, leave filesystem isolation on. The network sandbox is not a substitute for filesystem controls, and the minor friction of sandboxed file access is far cheaper than recovering from an accidental overwrite or a malicious prompt injection that breaks out of the project folder.
Think of the toggle as a compatibility shim, not a performance knob. It exists for environments where the operating system or orchestrator already handles isolation, and Claude’s own sandbox adds unnecessary complexity.
What the Update Actually Fixes
Beyond the new setting, 2.1.216 closes several practical holes that could let an agent reach places it should not.
Worktree isolation. Subagents can no longer redirect Git commands into a parent or sibling directory outside their own worktree. Previously, a subagent running inside your project could aim Git operations at your shared checkout or adjacent repositories. That matters because many developers keep multiple projects under a common parent folder. Now those boundary-crossing commands fail.
Symlink hardening at the .claude path. Workflow definitions and scheduled tasks used to follow symlinks when writing configuration. An attacker who could create a symlink from .claude to, say, your shell profile or SSH directory could potentially get the agent to write outside the project. The update stops this by refusing to follow symlinks at that path.
Safer rewinds. The /rewind command, which lets you roll back recent changes, now skips symlinked and hard-linked paths. Without this guard, a rewind operation could chase a symlink and overwrite a file far away from your repository. Claude now reports those skipped paths explicitly so you know the boundary held.
Resumed agents keep their restrictions. Background sessions that get stopped and later resumed used to fall back to default tool permissions. If you had intentionally restricted an agent so it could read but not write, a restart could silently restore broader access. Now the original restrictions are persisted and restored with the session.
Picking a Security Profile
Claude Code 2.1.216 organizes these controls into three profiles. Choose based on where you run the tool, not based on what feels fastest.
Default. Filesystem and network sandboxing both stay active. This is the right choice for local development on your laptop or workstation. It protects your home directory, system files, and neighboring projects without requiring you to manage containers.
Compatibility. Filesystem isolation is turned off, but the network sandbox remains. Restrict this profile to disposable containers or VMs where the filesystem is already ephemeral or strictly scoped. Do not use it because you are tired of typing passwords to let the agent access a protected folder.
Managed Hard Gate. Both sandbox layers stay on, and the profile expects additional container policies enforced by your orchestrator or security team. This is built for CI pipelines, remote dev environments, and enterprise setups where defense in depth is mandatory.
If you are unsure which one fits, start with Default. You can downgrade the protection later only after you have verified that your runtime environment genuinely isolates the filesystem by itself.
Upgrading Without Breaking Your Workflow
Ne traitez pas cela comme un correctif de routine que l'on installe un vendredi après-midi. Le processus de mise à niveau vers la version 2.1.216 est simple, mais les conséquences d'une mauvaise configuration ne le sont pas.
Tout d'abord, passez à la version 2.1.216 via votre gestionnaire de paquets ou votre installateur habituel. Choisissez ensuite l'un des trois profils d'isolation avant de lancer toute tâche d'agent. Ne mélangez pas les profils entre différentes sessions actives sans comprendre lequel prévaut.
Ensuite, exécutez les cinq tests de périmètre non destructifs décrits ci-dessous. Il s'agit de vérifications rapides et scriptées qui prouvent que le sandbox se comporte comme le profil le promet. Pendant les tests, générez des hachages sentinelles (sentinel hashes) pour les fichiers situés en dehors de votre dépôt de test jetable. Un hachage sentinelle est simplement une somme de contrôle (checksum) d'un fichier ou d'un répertoire sensible que vous souhaitez protéger. Après avoir exécuté les tests, comparez les hachages. Si quelque chose a changé, votre isolation présente une fuite.
Comparez également vos journaux (logs). Claude Code écrit les refus et les événements du sandbox dans ses journaux locaux. Recherchez des rejets explicites lorsqu'un hôte bloqué est atteint ou lorsqu'un sous-agent sort de son worktree. Les échecs silencieux sont pires que les échecs explicites, vérifiez donc que les journaux montrent que les garde-fous (guardrails) s'activent.
Enfin, déployez le changement progressivement. Commencez par un seul projet ou une branche hors production. Laissez la nouvelle version fonctionner pendant un jour ou deux avant de la déployer sur l'ensemble de votre équipe ou de votre flotte CI.
Cinq tests de périmètre qui prouvent que votre sandbox fonctionne
Exécutez toujours ces tests à l'intérieur d'un dépôt jetable rempli de fausses données. Ne les dirigez jamais vers du code de production, des identifiants réels ou une infrastructure en direct.
Périmètre réseau. Tentez d'atteindre deux points de terminaison (endpoints) : l'un que vous avez explicitement autorisé et l'autre que vous avez bloqué. Une simple requête HTTP vers un service de test public comme httpbin.org peut servir de cible autorisée, tandis qu'une requête vers un point de terminaison de métadonnées local ou une IP interne devrait échouer. Si la requête bloquée réussit, votre sandbox réseau est mal configurée.
Isolation du worktree. Depuis l'intérieur d'un sous-agent, exécutez une commande Git ciblant le répertoire parent. Par exemple, essayez git -C .. status ou demandez à l'agent de décrire des fichiers en dehors de son checkout. Avec le correctif de la version 2.1.216, cela doit échouer. Le sous-agent ne doit voir que son propre worktree.
Piège de lien symbolique (symlink). Créez un lien symbolique à l'intérieur de votre projet pointant vers un répertoire situé en dehors du dépôt, tel que /tmp/sentinel-target. Essayez ensuite d'enregistrer une tâche ou un workflow sous le chemin .claude qui écrirait via ce lien. Après l'enregistrement, vérifiez le répertoire externe. S'il est toujours vide, le durcissement des liens symboliques fonctionne.
Saut de rewind. Configurez un dossier à l'intérieur de votre dépôt contenant un lien symbolique vers un fichier système ou un autre répertoire. Exécutez /rewind sur ce dossier. Claude devrait lister les chemins avec liens symboliques ou liens physiques (hard-links) ignorés plutôt que de les suivre. Confirmez que la cible à l'extérieur du dépôt reste intacte.
Résurrection de session. Lancez un agent en arrière-plan avec une restriction stricte, comme la désactivation des outils d'écriture de fichiers. Mettez la session en pause ou arrêtez-la, puis reprenez-la. Essayez immédiatement de faire écrire un fichier par l'agent. Si la restriction est toujours active, le correctif pour les agents repris fonctionne. Si l'agent retrouve soudainement un accès complet aux outils, vous êtes toujours exposé.
Mot de la fin
Claude Code 2.1.216 vous offre plus de flexibilité que les versions précédentes, mais cette flexibilité s'accompagne d'un mandat clair : vérifiez avant de faire confiance. Le nouveau commutateur (toggle) du système de fichiers n'est pas là pour vous faciliter la vie au détriment de la sécurité. Il est là pour les ingénieurs qui ont déjà construit un socle renforcé sous l'outil. Les véritables améliorations de cette version sont les garde-fous silencieux qui empêchent les sous-agents de s'insinuer dans les répertoires parents, qui refusent de suivre les liens symboliques lors de l'écriture de configurations et qui se souviennent des règles même après une longue pause.
Exécutez les cinq tests. Vérifiez vos hachages sentinelles. Lisez les journaux. Ensuite, et seulement alors, laissez la nouvelle version gérer le travail réel.
Source : Claude Code v2.1.216 Release Notes
Communauté d'apprentissage optionnelle : GyaanSetu on Telegram