Approbations et sandbox dans Claude Code : où placer la barrière au quotidien

« De toute façon une boîte de confirmation s’affiche, donc ça devrait aller. »

Quand j’ai commencé, c’est exactement ce que je me disais. À chaque action de Claude Code, une demande apparaissait. Je lisais, je validais. J’avais l’impression de conduire prudemment.

Sauf que deux semaines plus tard, j’ai remarqué comment mes doigts bougeaient, et j’ai blêmi. J’appuyais sur Entrée par réflexe, sans lire le texte de confirmation. Dès qu’une opération devenait « la routine habituelle », je ne la vérifiais plus. Les git push, les écritures vers des API externes, je les laissais passer sans regarder le contenu. S’il n’y a pas eu d’accident, c’est uniquement parce que j’ai eu de la chance.

Une boîte de confirmation ne rend pas les choses plus sûres parce qu’on en met davantage. Trop nombreuses, on ne les lit plus. Trop rares, et des opérations irréversibles passent quand même. Aujourd’hui, je veux parler de cette « ligne de partage », non pas du détail des réglages, mais de la façon de décider, jour après jour.

Points clés

• L’approbation, ce n’est ni « tout bloquer » ni « tout laisser passer ». L’axe, c’est : les tâches réversibles vont vite, les tâches irréversibles vont lentement. Je trace la frontière selon que l’on peut faire undo ou non.
• Le permission mode (default / acceptEdits / plan / auto / dontAsk / bypassPermissions) se change selon la phase de travail. L’exploration en plan, la correction relue en acceptEdits.
• --dangerously-skip-permissions (soit le mode bypassPermissions) ne s’utilise pas au quotidien. À la place, on prend le mode auto ou le sandbox.
• Le sandbox restreint au niveau de l’OS le « périmètre » que Bash peut toucher. Il fonctionne sur macOS / Linux / WSL2, et ne fonctionne pas sous Windows natif.
• En équipe, on ne fait pas reposer « l’emplacement de la barrière » sur la motivation de chacun : on le fixe physiquement avec des règles deny et des hooks.

Pour la syntaxe des fichiers de configuration elle-même, voyez l’article jumeau Référence des permissions Claude Code, et pour les recettes concrètes combinant CLAUDE.md et permissions, CLAUDE.md × recettes de permissions. Ici, je me concentre uniquement sur la décision opérationnelle : « où arrêter ».

On trace la frontière selon « est-ce réversible ? »

Quand vous hésitez sur la ligne de partage, avant de jauger l’ampleur du risque technique, posez-vous une seule question.

« Ça, je peux l’annuler dans cinq minutes ? »

Lire un fichier, faire un grep, regarder un diff, lancer npm run build : ça se refait autant de fois qu’on veut. Au pire, un git checkout ramène tout. Donc je veux que ça tourne vite. À l’inverse, un git push, un déploiement en production, l’envoi d’un e-mail, une écriture dans une base externe : à l’instant où vous appuyez, le monde extérieur change. Impossible d’annuler. Donc je ralentis volontairement.

La répartition en trois niveaux que j’utilise souvent ressemble à ceci.

Opération	Décision	Raison
Lecture, grep, diff, build, test, lint	allow	Réversible. Je ne veux pas perdre de vitesse
Édition de code sur une branche	ask ou acceptEdits	Selon la maturité du dépôt
push, deploy, publish, envoi d’e-mail, écriture API externe	ask	Impact sur le monde extérieur, irréversible
Lecture de .env, rm -rf, git reset --hard, curl | sh	deny	Les dégâts en cas d’accident sont trop lourds

Ce qui fait le plus hésiter ici, c’est l’« édition ». L’édition n’est pas dangereuse par nature. Sur un dépôt personnel bien couvert par les tests, faire tourner les éditions à toute vitesse n’a rien d’effrayant. Ce qui fait peur, c’est plutôt de laisser l’édition en roue libre sur un dépôt proche de la production où les tests sont faibles. Le critère de décision n’est donc pas « est-ce que j’autorise l’édition ? », mais avec quoi je vérifie après l’édition. Si la commande de vérification est en place, on peut accélérer l’édition. Sinon, on la laisse en ask.

Pour deny, mieux vaut ratisser large « par précaution », ça ne coûte rien. La lecture de .env et les commandes destructrices, je les bloque dès le départ, en partant du principe que le jour où je les passerai en allow ne viendra jamais. Les instructions du genre « ignore les permissions et fais au plus vite », comme celles que je liste dans le recueil des prompts dangereux, reviennent justement à briser cette frontière exprès. Si elles sont dans deny, peu importe ce que dit le prompt : le cœur de Claude Code s’arrête.

Le permission mode se change selon la phase

Si allow/ask/deny règle « quoi » arrêter, le permission mode est le choix de vitesse : « combien on arrête en ce moment ». Avec Shift+Tab, on bascule entre default → acceptEdits → plan. La page officielle permission modes rassemble tous les modes, mais voici la correspondance à retenir pour l’usage réel.

Mode	Périmètre sans confirmation	Quand l’utiliser
default	Lecture seule	Dépôt inconnu, travail à mener prudemment
plan	Lecture seule (planifie sans éditer)	Comprendre la base de code avant d’agir
acceptEdits	Lecture + édition dans le dossier de travail	Corriger en relisant soi-même
auto	Presque tout (un classifieur vérifie en arrière-plan)	Long travail, réduire la fatigue de validation
dontAsk	Uniquement ce qui a été mis en allow	CI ou scripts, environnement verrouillé
bypassPermissions	Tout (sans vérification)	Uniquement dans un conteneur / une VM isolés

Mon usage est simple. L’entrée d’un nouveau travail se fait en plan. Je laisse Claude lire d’abord, sortir le plan d’action, et je vérifie que la direction est bonne avant de le laisser bouger. Une fois la direction fixée, je redescends en acceptEdits pour qu’il édite d’un coup, puis je relis l’ensemble du résultat avec git diff. Plutôt que d’approuver ligne par ligne, tout relire ensuite permet de lire avec plus de concentration. C’est une façon de faire de « je regarde toujours à la fin » un mécanisme, dans la continuité directe de l’idée « confier le portier à la machine » développée dans l’ingénierie du harnais (le harnais, c’est l’échafaudage qui encadre l’agent).

Une précaution. Dans tous les modes sauf bypassPermissions, l’écriture dans les protected paths n’est jamais auto-approuvée. Ce sont des emplacements comme .git, .claude, .bashrc, .npmrc : s’ils cassent, c’est le dépôt ou la configuration elle-même qui meurt. Même en éditant tranquillement en acceptEdits, une confirmation surgit ici. Ce n’est pas une gêne, voyez-le comme le dernier filet de sécurité.

Se passer de --dangerously-skip-permissions

Pour régler le problème « trop de confirmations, c’est pénible », beaucoup tendent la main vers --dangerously-skip-permissions (soit le mode bypassPermissions). Comme son nom l’indique, ce drapeau coupe toutes les vérifications.

Si vous l’utilisez en continu dans le dialogue quotidien, ce n’est plus un « agent sous supervision ». C’est juste qu’il n’y a pas encore eu d’accident. La documentation officielle précise elle-même que ce mode est « uniquement dans un conteneur / une VM isolés » : sauf pour les cas les plus extrêmes comme rm -rf / ou rm -rf ~, aucun prompt n’apparaît. La défense contre les injections de prompt y est également nulle.

Mais le ressenti « c’est pénible » est, lui, parfaitement légitime. Donc ce qu’il faut écraser, c’est le nombre de confirmations, pas le filet de sécurité. Il existe deux alternatives.

La première, c’est le mode auto. Il fait disparaître les confirmations, mais un autre modèle classifieur observe chaque opération en arrière-plan et bloque les actions risquées : curl | bash, déploiement en production, push direct sur main, force push. Si vous dites « ne push pas » au fil de la conversation, cela agit aussi comme un signal de blocage temporaire. Les confirmations diminuent, mais les opérations dangereuses sont stoppées. C’est tout autre chose que bypassPermissions. Cela dit, le mode auto est en research preview : ce n’est pas un outil pour escamoter entièrement la relecture des opérations sensibles, mais à réserver aux « travaux dont la direction est fiable ».

La seconde, c’est le sandbox. J’en parle au chapitre suivant.

Si vous voulez réduire les confirmations, prenez d’abord acceptEdits ou auto, et si ça ne suffit toujours pas, le sandbox. bypassPermissions, on l’admet comme réservé aux conteneurs. En raisonnant dans cet ordre, il ne reste pratiquement aucune raison de retirer tout le filet de sécurité.

Le sandbox enferme le « périmètre accessible » au niveau de l’OS

Si l’approbation demande « as-tu le droit de faire cette opération ? », le sandbox rétrécit, au niveau de l’OS, le périmètre même des fichiers et du réseau que Bash peut toucher. L’approbation, c’est la « vérification avant l’exécution » ; le sandbox, c’est le « mur pendant l’exécution ». Ce sont des couches différentes.

Là où ça devient précieux, c’est qu’il comble le point faible de l’approbation. L’approbation juge à partir de la chaîne de caractères de la commande : si npm run build fait quelque chose d’inattendu en coulisses, elle ne s’en aperçoit pas. Avec le sandbox, en revanche, cette commande ne peut écrire, par défaut, qu’à l’intérieur du dossier de travail. Même si elle ne se comporte pas conformément à son nom, l’OS la bloque physiquement.

Quand vous lancez /sandbox, un panneau de configuration s’ouvre et propose deux modes.

• auto-allow : à l’intérieur du sandbox, Bash s’exécute sans confirmation (c’est sûr puisque le périmètre est cloisonné). Seules les opérations qui sortent du périmètre repassent par l’approbation classique.
• regular permissions : même à l’intérieur du sandbox, les confirmations s’affichent comme d’habitude. Le contrôle est fort, mais les confirmations nombreuses.

Autrement dit, c’est parfait pour qui pense « je veux moins de confirmations, mais l’idée que tout s’exécute me fait peur ». Comme on est protégé par le périmètre, pas besoin de demander à chaque fois.

Une contrainte importante toutefois. Le sandbox fonctionne uniquement sur macOS / Linux / WSL2, et pas sous Windows natif. Les utilisateurs Windows doivent faire tourner Claude Code à l’intérieur de WSL2. Si vous ne pouvez pas utiliser WSL, ou si vous travaillez sur du Windows brut, n’attendez rien du sandbox et durcissez plutôt votre répartition allow/ask/deny. Penchez en particulier vers ask pour tout ce qui touche au deploy, au publish et aux secrets. C’est le compromis réaliste sous Windows.

La configuration du sandbox prend cette forme. On n’ouvre une brèche explicite que pour les outils qui ont besoin d’écrire hors du dossier de travail (par exemple kubectl qui touche à ~/.kube).

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/.aws", "~/.ssh"]
    }
  }
}

failIfUnavailable: false signifie « si le sandbox n’est pas disponible dans l’environnement, n’émettre qu’un avertissement et retomber sur une exécution normale ». À l’inverse, si l’organisation veut rendre le sandbox obligatoire, passez-le à true pour bloquer le démarrage lui-même. Autre point discrètement important : denyRead. Par défaut, le sandbox peut lire presque tous les fichiers, donc bloquer explicitement les secrets comme ~/.aws ou ~/.ssh est plus rassurant.

Le point de départ d’une configuration pour « l’usage quotidien »

En condensant ces décisions dans un seul fichier, ce point de départ suffit largement pour l’usage de tous les jours. Le sens fin de la syntaxe (la différence entre Bash(npm run build) et Bash(npm*), par exemple) est traité dans la référence des permissions.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "plan",
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npx wrangler pages deploy *)",
      "Bash(node scripts/outreach-send-mails.mjs --send)",
      "WebFetch(domain:api.gumroad.com)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Bash(rm -rf *)",
      "Bash(git reset --hard *)",
      "Bash(curl * | sh)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false
  }
}

Ce que fait cette configuration tient en trois points seulement. Faire tourner vite la lecture et la vérification. Toujours arrêter les opérations à impact externe. Interdire d’emblée ce qui est manifestement dangereux. Si j’ajoute defaultMode: "plan", c’est parce que je veux commencer chaque nouvelle session par « lire d’abord, puis planifier ». Ensuite, il suffit de monter en acceptEdits avec Shift+Tab au fil du travail.

Le fait que l’édition (Edit / Write) ne figure ni dans allow ni dans ask est intentionnel. Je veux la contrôler côté mode (acceptEdits). Brider l’édition à la fois par une règle et par un mode rend impossible de savoir lequel agit. L’édition par le mode, les effets de bord externes par les règles : séparer les rôles ainsi, et la tête se clarifie.

En équipe, on fixe « l’emplacement de la barrière » par le physique

Jusqu’ici, on parlait de l’individu. En équipe, un problème supplémentaire apparaît : la ligne de partage varie d’une personne à l’autre. Il y a les prudents, et il y a ceux qui veulent tout faire tourner en bypassPermissions. Si on s’en remet à la motivation et au bon sens, c’est l’usage de la personne la plus laxiste qui devient la ligne effective de l’équipe.

Alors, les endroits où l’on veut arrêter, on ne les confie pas au jugement humain : on les fixe par le physique. Trois exemples concrets.

1. Stopper l’introduction de secrets avant le commit. Un hook PreToolUse vérifie mécaniquement, avant git add, que .env n’a pas été mis en staging. Avant même que quelqu’un se dise « ah, ça je n’aurais pas dû l’ajouter », le commit est arrêté.

2. Forcer le build avant le deploy. Ne croyez pas le « j’ai fait passer le build en local ». Avant la commande de déploiement, un hook lance impérativement npm run build.

3. Lancer la vérification automatiquement après une édition. Après Edit / Write, faire tourner npm run test. La vérification s’exécute même pour une retouche minime, donc on n’avance pas avec du code cassé.

La configuration minimale ressemble à ceci. Les hooks ne sont pas meilleurs en grand nombre : un hook qui arrête et un hook qui vérifie, c’est à peu près le seuil au-delà duquel l’usage devient fragile.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo 'Blocked: .env staged' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(npx wrangler pages deploy*)",
        "hooks": [{
          "type": "command",
          "command": "npm run build"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npm run test || true"
        }]
      }
    ]
  }
}

Sous Windows, il suffit de remplacer la partie grep par findstr ou un petit script Node pour que ça fonctionne. L’important n’est pas la commande elle-même, mais les trois formes : « arrêter avant le commit / build avant le deploy / vérifier après l’édition ». Pour brider au niveau de l’organisation, une autre option consiste à passer bypassPermissions à disable via les managed settings et à rendre le sandbox obligatoire. À l’échelle d’une équipe, concevoir les règles d’usage d’un bout à l’autre sur la page de consultation finit par être, au fond, le chemin le plus rapide.

Les erreurs les plus courantes

Toutes les trois, c’est moi ou mon entourage qui les avons réellement commises.

Tout mettre en ask et se sentir tranquille

Le premier jour, ça paraît sûr. Mais une semaine plus tard, on commence à valider sans lire le texte de confirmation. C’est plus dangereux qu’un deny faible, parce qu’il reste l’illusion d’« avoir vérifié ». Avant d’aligner des ask, commencez par solidifier deny.

--dangerously-skip-permissions devient un tic

Une fois qu’on a goûté au « tiens, c’est rapide », on n’en revient plus. Sauf qu’on a juste retiré la supervision. Si les confirmations vous pèsent, prenez le mode auto ou l’auto-allow du sandbox. Il n’y a nulle part de raison de retirer le filet de sécurité tout entier.

Confondre build réussi et release réussie

Ça revient sans cesse, aussi bien en gestion de contenu qu’en développement. Le build local passe, mais l’URL publique est encore l’ancienne, une seule langue n’est pas à jour, le CTA est cassé sur mobile. Ni l’approbation ni le sandbox ne préviennent cet échec-là. Ce qu’il faut, c’est une vérification après publication. J’ai fait ce « je croyais l’avoir publié » un nombre incalculable de fois.

FAQ

Q. Quelle différence entre le mode auto et l’auto-allow du sandbox ? R. La manière de protéger diffère. Le mode auto fait juger par un modèle classifieur « cette opération est-elle dangereuse ? » et bloque en conséquence. L’auto-allow du sandbox, lui, assure la sécurité non pas par le contenu de l’opération mais en enfermant son « périmètre accessible » au niveau de l’OS. Le premier protège par le jugement, le second par le périmètre. On peut aussi combiner les deux.

Q. Le sandbox est-il utilisable sous Windows ? R. Pas sous Windows natif. En faisant tourner Claude Code à l’intérieur de WSL2, c’est utilisable. Si vous travaillez sur du Windows brut, ne comptez pas sur le sandbox : penchez vers ask pour le deploy, le publish et les secrets, et durcissez deny.

Q. Comment choisir entre le mode plan et le mode acceptEdits ? R. plan, c’est « lire seulement, ne pas éditer », pour la phase où l’on comprend la base de code et où l’on établit le plan d’action. acceptEdits, c’est « laisser passer sans confirmation les éditions dans le dossier de travail », pour la phase où la direction est fixée et où l’on corrige d’un coup. Je commence en plan, et une fois d’accord, je redescends en acceptEdits.

Q. Comment exécuter, une seule fois, une opération mise en deny ? R. deny est imposé par le cœur de Claude Code, donc aucun prompt ne peut l’assouplir (c’est tout l’intérêt de deny). Si c’est vraiment nécessaire, retirez-la sur le moment des settings, exécutez, puis remettez-la. Cette manipulation même de « l’avoir retirée temporairement » agit comme un frein sur les opérations dangereuses.

Q. Les hooks et les permissions ne font-ils pas double emploi ? R. Non. Les permissions contrôlent « a-t-on le droit d’exécuter cette opération », les hooks contrôlent « qu’est-ce qui doit impérativement tourner avant ou après l’exécution ». Les vérifications déterministes comme stopper l’introduction de secrets ou builder avant le deploy relèvent des hooks.

Le résultat après l’avoir testé

J’ai réinjecté cette approche telle quelle dans la daily automation de ce site. Ce qui a le plus changé, ce n’est pas tant la qualité de sortie de l’IA elle-même que la clarté sur « à quel moment l’humain s’arrête ».

Avant, l’usage était flou, du genre « faire avancer une chose », et il arrivait qu’un run se termine sur une petite retouche d’un article existant. Aujourd’hui, le flux est fixé : plan pour le plan d'action → acceptEdits pour l'édition → build par hook avant le deploy → vérification mobile dans toutes les langues après publication. Depuis que j’ai cessé d’utiliser bypassPermissions pour passer à acceptEdits + sandbox, les sueurs froides du genre « je me suis retrouvé à faire quelque chose à l’extérieur sans m’en rendre compte » ont disparu.

Plutôt que de tout confier à une IA intelligente, placer une respiration juste avant les opérations irréversibles. Cela paraît un détour, mais c’est cette voie-là qui permet de faire tourner les choses sereinement chaque jour. Pour commencer, gardez le cheatsheet gratuit à portée de main et remplissez votre propre liste deny, une ligne à la fois.