Guide Approval et Sandbox pour Claude Code | Reglages surs pour le travail quotidien

Activer approval ne suffit pas pour dire que Claude Code est “safe”. Quand il y a trop de confirmations, on ne les lit plus. Quand allow est trop large, l’agent peut executer des actions qui auraient du rester humaines.

Cette page repond a la vraie question apres les premiers pas : quelles actions doivent etre automatiques, lesquelles doivent demander approval, et lesquelles doivent etre interdites. Pour la vision d’ensemble, lisez aussi harness engineering, permissions guide et security failure cases.

Approval n’est pas la meme chose que securite

Une configuration solide repose en general sur trois couches :

Controle	Role	Exemples
permission rules	Definir allow / ask / deny	secrets, commandes destructrices, deploy
approval flow	Arreter avant les effets irreversibles	git push, publish, send
sandbox	Reduire la surface du shell	build, verification, scripts exploratoires

Les references officielles restent permissions, settings et hooks. L’idee la plus utile est simple : ce qui est reversible doit aller vite, ce qui ne l’est pas doit aller lentement.

Une repartition simple pour le quotidien

Action	Regle conseillee	Pourquoi
Lire des fichiers, chercher, inspecter un diff	allow	Risque faible
Build, test, lint, analytics	allow	Il faut garder la vitesse
Modifier du code sur une branche	ask ou allow de session	Selon la maturite du repo
git push, deploy, publish, send	ask	Effet externe
Lire .env, rm -rf, git reset --hard	deny	Rayon d’explosion trop fort
Ecritures vers des APIs externes	ask	Impact reel

Base utile pour .claude/settings.json

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Read",
      "Grep",
      "Glob",
      "Bash(npm run build)",
      "Bash(npm run test)",
      "Bash(node scripts/analytics-report.mjs *)"
    ],
    "ask": [
      "Edit",
      "Write",
      "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
  }
}

Si le sandbox n’est pas disponible dans votre environnement, compensez en mettant davantage d’actions a effet externe dans ask.

Les hooks reduisent les erreurs repetitives

{
  "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"
        }]
      }
    ]
  }
}

Le schema utile est toujours le meme :

• bloquer les secrets avant le commit
• forcer le build avant le deploy
• executer une verification apres edition

Trois workflows concrets

1. Site de contenu

Le vrai workflow n’est pas “ecrire un article”. C’est : lire les analytics, choisir un sujet, produire les locales, build, deploy, ouvrir l’URL publique et verifier le rendu mobile avec Playwright.

2. Repo applicatif

Claude Code peut lire, analyser des diffs, refactorer sur une branche et lancer les tests. Push vers une branche partagee, migrations, APIs de production et infra doivent rester en ask.

3. Outreach et back-office

Recherche et brouillons peuvent etre automatiques. Envoi d’email, ecriture dans un CRM ou publication doivent demander approval.

Les trois erreurs les plus courantes

1. Mettre tout en ask puis approuver sans lire.
2. Normaliser --dangerously-skip-permissions.
3. Confondre build reussi et publication reussie.

La troisieme erreur est frequente sur les sites multilingues : la build passe, mais l’URL publique est encore ancienne ou une locale manque.

Ce que nous avons change aujourd’hui

Sur ClaudeCodeLab, la regle quotidienne est devenue plus stricte :

• publier un nouvel article a chaque run
• faire aussi avancer une tache existante
• verifier le mobile avec Playwright
• controler toutes les URLs de langues pour le meme slug en production

La securite vient de regles operatoires claires, pas d’une simple phrase “faites attention”.

Suite logique

Commencez par le cheatsheet gratuit. Si vous voulez des reglages, hooks et exemples prets a copier, ouvrez la English products page. Si vous avez besoin d’aide pour le rollout, la review ou les limites d’automatisation, utilisez la consultation page.