Le bouton « fais-le, toi »

Ce que c'est et pourquoi ça compte

En mode Manual, Claude Code vous demande la permission avant la plupart des actions. Au début, vous lisez chaque question. Au bout d'un moment, vous appuyez sur oui sans lire, et à partir de là la permission ne vous protège plus.

Le bouton « fais-le, toi », c'est l'inverse : vous décidez une seule fois, à froid, ce que Claude peut faire seul et ce qu'il ne peut pas faire. Libre dans le projet : modifier les fichiers, lancer les tests, démarrer le serveur. Bloqué sur trois choses difficiles à annuler : supprimer, publier, toucher la vraie base de données.

Il faut deux éléments : un mode de permission, qui décide à quel point Claude vous demande, et un fichier de règles dans le projet, qui dit ce qui passe toujours, ce qui demande toujours et ce qui est interdit.

1. Le mode

Je travaille en accept edits : Claude modifie les fichiers du projet sans demander, et tout le reste passe par les règles ci-dessous. Il accepte aussi seul quelques commandes de base sur les fichiers, comme mkdir, mv, cp et rm, mais seulement dans le dossier du projet.

Pour l'activer, appuyez sur Shift+Tab jusqu'à lire « accept edits on » sous le prompt. Dans les versions récentes, la session démarre déjà en auto mode, où un second modèle contrôle les actions à votre place : le premier Shift+Tab vous amène en Manual, le deuxième en accept edits. Ou vous le choisissez au démarrage, depuis le terminal :

claude --permission-mode acceptEdits

Avant de confier un travail à Claude, regardez toujours cette ligne. Auto est pratique et bloque les actions risquées, mais la documentation elle-même dit que ça ne garantit pas la sécurité. Avec accept edits, vous savez exactement ce qui passe tout seul, et les règles valent dans les deux.

2. Les règles, une fois pour toutes

Créez le fichier .claude/settings.json dans le dossier du projet. S'il existe déjà, ne l'écrasez pas : ajoutez la partie « permissions » à ce qui s'y trouve. Le mien ressemble à ça :

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run test *)",
      "Bash(npm run dev *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(npm publish *)",
      "Bash(vercel *)",
      "Bash(npx vercel *)",
      "Bash(supabase db push *)",
      "Bash(psql *)",
      "Read(./.env.production)"
    ]
  }
}

Mettez vos commandes à la place des miennes (les tests, le serveur, le déploiement, le client de votre vraie base de données). Attention : en accept edits, même rm dans le projet passerait tout seul, c'est pour ça qu'il est dans les deny.

Ce que fait chaque partie

• defaultMode : le mode dans lequel la session démarre, dans le terminal. Vous démarrez en accept edits même si le mode par défaut serait auto. Le flag --permission-mode l'emporte sur le fichier.
• allow : les commandes que Claude lance sans demander : tests, lint, serveur de développement. Bash(npm test *) couvre npm test tout seul et avec n'importe quelle option après.
• ask : les commandes pour lesquelles vous voulez une question à chaque fois, dans n'importe quel mode, auto compris. git push envoie le code en ligne : je veux le voir avant.
• deny : ce qui ne doit jamais arriver : supprimer des fichiers, le push forcé, publier, le déploiement, la vraie base de données. vercel et npx vercel sont deux lignes parce que la règle sur vercel ne voit pas la commande avec npx devant.
• Read(./.env.production) : Claude ne lit pas le fichier avec les clés de production, ni avec ses propres outils ni avec cat, et il ne peut pas le modifier.

Vous n'avez pas besoin d'écrire le fichier à la main. Vous pouvez le faire adapter par Claude :

Lis le package.json et les scripts de ce projet. Ensuite adapte ce fichier .claude/settings.json : dans allow, mets les vraies commandes des tests, du lint et du serveur de développement ; dans deny, les commandes qui suppriment des fichiers, publient l'app, font le déploiement ou touchent la base de données de production. Ne mets rien dans allow qui supprime ou envoie quelque chose en ligne. Montre-moi le fichier avant de l'enregistrer.

[colle ici le fichier]

Quand Claude enregistre le fichier, il vous demande la permission même en accept edits : c'est normal, le dossier .claude est protégé.

3. Trois choses à savoir

Le deny gagne toujours

Claude Code vérifie les règles dans cet ordre : d'abord deny, puis ask, puis allow. C'est la première qui correspond qui décide. Un allow n'ouvre pas de brèche dans un deny, même s'il est plus précis. Et les deny valent dans tous les modes.

Dans mon fichier : git push --force est à la fois dans le ask et dans le deny, et le deny gagne. En revanche, git push origin main --force, le deny ne la voit pas, parce qu'elle ne commence pas par « git push --force ». Elle commence quand même par « git push », et le ask vous pose la question. C'est pour ça que je garde les deux lignes.

Les règles lisent le texte de la commande

Les règles lisent le texte de la commande : bash -c 'rm -rf build' ou /bin/rm passent sous « Bash(rm *) ». La règle ne les reconnaît pas, et à ce moment-là ce sont le mode et les autres règles qui décident.

Pour une vraie garde, utilisez un hook PreToolUse (le gardien du TIPS 05) ou la sandbox (/sandbox). Le hook lit tout le texte de chaque commande avant qu'elle ne parte, même à l'intérieur de bash -c. Avec la sandbox, c'est le système d'exploitation qui limite ce que les commandes écrivent hors du projet et les sites auxquels elles se connectent. Dans le projet, en revanche, elle laisse écrire : un rm à cet endroit, seul le hook l'arrête.

Le mode sans contrôles

Le mode sans aucun contrôle (--dangerously-skip-permissions), utilisez-le seulement dans un conteneur ou une machine virtuelle, jamais sur l'ordinateur avec vos fichiers. La documentation aussi ne le recommande que dans des environnements isolés. Si vous voulez moins de questions sur votre ordinateur, la bonne voie est accept edits avec les règles, ou auto.

4. Vérifiez

Tapez /permissions dans Claude Code : vous voyez toutes les règles actives et le fichier d'où vient chacune. S'il manque une règle, en général le fichier n'est pas au bon endroit ou le JSON contient une erreur, comme une virgule manquante.

Ensuite, faites un vrai test. Écrivez à Claude :

Crée un fichier vide appelé test-permissions.txt. Ensuite essaie ces trois commandes, une par une, et pour chacune dis-moi ce qui s'est passé : bloquée par une règle, tu m'as demandé la permission, ou elle est partie toute seule.
- npm test (ou la commande des tests de ce projet)
- rm test-permissions.txt
- git push --dry-run
Si une commande est bloquée, ne cherche pas d'autres moyens de la lancer.

Voici ce que vous attendez : tests partis tout seuls, rm bloqué, git push avec la question (avec --dry-run, rien n'est envoyé en ligne). Le fichier de test, vous le supprimez vous-même ensuite : Claude ne peut pas.

Les erreurs les plus courantes

• Copier le fichier sans changer les commandes : si vos tests ne se lancent pas avec npm test, le allow ne sert à rien et Claude vous demande à chaque fois. Mettez les vraies commandes de votre projet.
• Travailler en accept edits sans rm dans les deny : dans le projet, rm passe tout seul. Gardez-le dans les deny et supprimez vous-même les fichiers à jeter.
• Croire que le deny couvre toutes les formes de la commande : bash -c ou /bin/rm passent. Pour une vraie garde, ajoutez le hook ou la sandbox.
• Compter sur les instructions dans le chat, du genre « ne supprime rien » : elles orientent Claude mais ne bloquent rien. Ce qui ne doit jamais arriver va dans les deny.
• Ne pas regarder dans quel mode vous êtes : la session peut démarrer en auto sans que vous l'ayez choisi. Avant un long travail, lisez la ligne sous le prompt.

Check-list

• Mode choisi et vérifié sous le prompt
• .claude/settings.json avec les commandes de votre projet
• rm, déploiement, publish et vraie base de données dans les deny
• git push dans le ask
• Règles vérifiées avec /permissions
• Test fait : tests libres, rm bloqué, push avec question
• Pas de --dangerously-skip-permissions sur votre ordinateur

Questions fréquentes