Faire tourner Claude Code sans surveillance, sans le regretter

Commencez par la machine, pas par les options

Chaque garde-fou ci-dessous est plus simple quand l’agent tourne sur une machine qui ne contient rien d’autre. Sur votre portable, “tout autoriser” veut dire vos e-mails, votre gestionnaire de mots de passe, vos identifiants de production et vos photos. Sur une machine dédiée avec un seul dépôt et un seul jeton à portée limitée, “tout autoriser” veut dire ce dépôt et ce jeton. Anthropic recommande elle-même de réserver le mode bypass à un environnement isolé. Placez l’agent dans un tel environnement, et le reste de cette page devient plus simple.

Les modes de permission de Claude Code

Claude Code a quatre modes. Choisissez-en un par tâche, pas un pour toujours.

• default. Demande avant de modifier des fichiers et avant les commandes shell. Bien pour le travail interactif. Mal adapté à la nuit.
• acceptEdits. Modifie les fichiers du répertoire de travail sans demander. Demande toujours avant les commandes shell. Un bon réglage intermédiaire pour les refactorings où les tests font juge.
• plan. Lit et réfléchit, mais ne change rien. Utilisez-le pour obtenir un plan à relire avant la vraie exécution.
• bypassPermissions. Aucune question. C’est le mode sans surveillance. Ne l’utilisez que sur une machine isolée, avec les règles deny ci-dessous en place.

Choisissez le mode au lancement.

claude --permission-mode acceptEdits

Ou faites-en le mode par défaut d’un projet dans son fichier de réglages. Vous pouvez le commiter pour que toute l’équipe le partage.

// .claude/settings.json
{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Les règles deny fonctionnent dans tous les modes

C’est la partie que la plupart des gens ratent. Les règles de permission s’ajoutent au mode. Une règle deny bloque l’action même en mode bypass. Les règles deny sont donc le vrai filet de sécurité des exécutions sans surveillance. Les règles allow pré-approuvent ce que vous accepteriez à chaque fois, pour que l’agent ne bloque pas dessus.

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm test:*)",
      "Bash(npm run lint:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git push origin HEAD:*)"
    ],
    "deny": [
      "Bash(git push:*--force*)",
      "Bash(git push origin main:*)",
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)"
    ]
  }
}

Lisez la liste deny comme une politique, car c’en est une. Pas de force push. Pas de push sur main. Pas de suppression récursive. Pas de requêtes sortantes inventées par l’agent. Pas de lecture des fichiers de secrets. Adaptez-la à votre projet, mais gardez une liste deny sur chaque machine sans surveillance.

Des hooks pour les règles qu’un motif ne sait pas exprimer

Certaines règles dépendent du contexte. Un hook exécute un script avant un appel d’outil. Il peut l’approuver, le bloquer ou le modifier. Un hook courant bloque toute commande qui mentionne un nom d’hôte de production, quelle que soit la commande.

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "./scripts/block-prod.sh" }
        ]
      }
    ]
  }
}

Le script lit l’appel d’outil sur l’entrée standard. Il le bloque en sortant avec un code non nul. Gardez des hooks petits et ennuyeux. Un hook qui peut échouer sans que personne ne le remarque est pire que pas de hook du tout.

Git est votre meilleur garde-fou

Les réglages de l’agent sont une couche. Le dépôt en est une deuxième, qui ne se soucie pas de l’agent qui tourne.

• Protégez main. Exigez une pull request et une CI au vert pour merger. Ainsi, un push malvenu ne peut rien faire entrer.
• Une branche par tâche. L’agent part d’une branche neuve et ne pousse que celle-ci.
• Donnez à l’agent un jeton qui peut pousser des branches et ouvrir des pull requests, et rien d’autre. Pas de droits admin. Pas de droits de suppression. Un jeton GitHub à granularité fine, limité à un seul dépôt, fait exactement cela.
• Les tests font juge. Si la suite échoue, la pull request reste rouge et vous le voyez le matin.

Identifiants : le minimum, et séparés

Ne mettez jamais un identifiant personnel sur une machine sans surveillance. Créez un compte ou un jeton séparé pour l’agent, avec la portée la plus réduite qui lui permet de faire la tâche. La préproduction, pas la production. La lecture seule quand la lecture suffit. Si l’agent doit se connecter à un service via un navigateur, utilisez un compte de test. Renouvelez le jeton à la fin du projet.

Des exécutions headless avec un plafond

Pour une tâche scriptée, le mode print exécute un seul prompt puis se termine. Donnez-lui une limite de tours, pour qu’un agent perdu ne tourne pas en boucle toute la nuit.

claude -p "Fix the failing tests in packages/api and open a PR" \
  --permission-mode acceptEdits \
  --max-turns 60

Enregistrez la sortie dans un fichier. Le matin, vous voulez lire ce qu’il a fait, pas le deviner.

Les mêmes règles pour Codex

Codex CLI sépare deux questions. Quand demande-t-il une approbation ? Et à quoi peut-il toucher ? Pour une tâche sans surveillance dans un seul dépôt, la bonne combinaison est : ne jamais demander, et n’écrire que dans l’espace de travail.

codex -a never -s workspace-write exec "Fix the failing tests and commit"

Codex a aussi une option qui supprime à la fois les approbations et le sandbox. Traitez-la exactement comme le mode bypass de Claude Code. Sur une machine isolée, ou pas du tout.

La liste des interdits

Quel que soit l’outil, un agent sans surveillance ne doit pouvoir faire aucune de ces choses. Si votre configuration en permet une, corrigez-la avant la première nuit.

• Pousser sur une branche protégée, ou faire un force push où que ce soit.
• Lire ou envoyer un secret dont il n’avait pas besoin pour la tâche.
• Toucher aux données de production, même en lecture.
• Dépenser de l’argent. Pas de console cloud, pas de page de paiement, pas de compte publicitaire.
• Envoyer des messages à des personnes. Ni e-mail, ni chat, ni réseaux sociaux.
• Supprimer quoi que ce soit hors de l’arbre de travail.