Autorisations Claude Code : protéger .env, Git et les commandes dangereuses

Lors de la configuration de Claude Code, les développeurs se heurtent souvent à un faux dilemme : confirmer sans cesse des commandes de lecture anodines, ou activer le contournement complet (--dangerously-skip-permissions) et risquer une fuite depuis .env, un git push --force accidentel ou un environnement de projet endommagé.

Ces deux extrêmes sont inefficaces. Une configuration sûre applique le principe du moindre privilège : les droits de lecture, d’écriture, d’exécution shell et de contrôle de version doivent être clairement séparés.

---

1. Carte des autorisations : de la lecture à l’impact externe

Répartissez les fichiers et les commandes dans quatre niveaux d’accès :

Niveau	Opérations	Politique par défaut	Exemples
1. Lecture du code	Consulter les fichiers du projet	Autorisé (sans confirmation)	cat, grep, lire le code source dans src/
2. Secrets et configuration	Accéder à .env, aux clés, aux tokens	Strictement interdit	.env*, id_rsa, *.pem, credentials.json
3. Modification de fichiers	Écrire et modifier du code	Autorisé dans le périmètre du workspace	write_to_file, replace_file_content
4. Shell et Git dangereux	Gestionnaires de paquets, opérations destructrices	Validation manuelle obligatoire	rm -rf, git push --force, npm publish, DROP TABLE

---

2. Isoler les fichiers .env et les secrets du projet

Transport Layer Security (TLS) chiffre le trafic API pendant son transport. Il n’empêche toutefois pas des identifiants confidentiels d’entrer dans la fenêtre de contexte du modèle, les journaux d’erreurs ou les synthèses de handoff.

Pour que Claude Code n’ingère pas d’identifiants privés :

1. Ajoutez à .gitignore tous les fichiers d’environnement contenant des secrets.
2. Fournissez un modèle .env.example propre, avec des valeurs fictives ; l’agent comprend ainsi les noms de variables sans voir les valeurs d’exécution.
3. Ajoutez une règle de frontière stricte dans CLAUDE.md ou AGENTS.md :

## Règle de protection des secrets

- Ne jamais inspecter, afficher ou transmettre le contenu de `.env`, `.env.local` ou de fichiers de clés privées.
- Pour vérifier les clés de configuration requises, examiner `.env.example`.

[!IMPORTANT] Gestion des clés API : votre clé API Claude Code est configurée dans votre environnement local et ne doit jamais être commitée dans les fichiers du dépôt. Suivez le flux d’intégration de la documentation BetterToken pour Claude Code.

.gitignore évite un commit accidentel, mais n’empêche pas l’agent de lire un fichier. Les consignes de CLAUDE.md ou AGENTS.md expriment une intention sans constituer une frontière technique. Associez-les aux règles de permission actuelles et à la sandbox du système :

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(secrets/**)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "filesystem": {
      "denyRead": [
        "./**/.env",
        "./**/.env.*",
        "./secrets"
      ]
    }
  }
}

Le deny Read couvre les outils de fichiers intégrés et les commandes reconnues. Un subprocess Python ou Node arbitraire peut lire autrement ; la sandbox fournit donc la limite OS. failIfUnavailable et allowUnsandboxedCommands provoquent un refus plutôt qu’un fallback sans isolation. La sandbox n’est pas prise en charge sous Windows natif : utilisez WSL2 ou un conteneur. Dans un environnement administré, la policy doit être verrouillée pour qu’un projet ne puisse pas l’affaiblir.

---

3. Checklist priorisée pour Git et les commandes

Pour chaque tâche exécutée avec Claude Code, appliquez d’abord cette hiérarchie :

L'agent propose une commande
  │
  ├─> Contient-elle un motif destructeur (rm -rf, drop, force push) ?
  │     └─> OUI : la refuser ou l'exécuter manuellement sous supervision
  │
  └─> Touche-t-elle aux internes de .git, aux fichiers .env ou à des réseaux externes ?
        │
        ├─> OUI : demander une justification explicite et réduire son périmètre
        │
        └─> NON : autoriser l'exécution dans la branche cible

Garde-fous étape par étape

1. Étape 1 : bloquer les mutations Git. N’autorisez jamais un push automatisé direct vers main sans git diff --check manuel et sans exécution des tests.
2. Étape 2 : isoler l’installation de paquets. Les commandes telles que npm install <package> ou les scripts curl distants doivent être vérifiés manuellement afin d’éviter les dépendances non fiables et les risques de chaîne d’approvisionnement.
3. Étape 3 : limiter le périmètre des répertoires. Restreignez le workspace de l’agent à un dossier de fonctionnalité précis ou à un Git worktree dédié.

---

4. L’accès à la production est une frontière distincte

Les permissions locales ne remplacent ni IAM, ni la politique réseau, ni l’approbation du système de production. Préférez l’absence d’accès. Si le diagnostic l’exige, délivrez un rôle read-only limité à la ressource et à courte durée. Une écriture demande une approbation séparée précisant commande, cible, fenêtre, validation, observateur et rollback. Si le résultat est inconnu, lisez d’abord l’état réel. Les journaux gardent identité, ressource, action et résultat sans secret ni payload sensible, puis les credentials temporaires sont révoqués. Ne copiez jamais un credential dans HANDOFF.md.

5. Valider les autorisations dans un workspace de test

Avant d’accorder à Claude Code l’accès à un dépôt critique, effectuez une validation en sandbox :

1. Créez une branche de test temporaire : git checkout -b test/permission-check.
2. Ajoutez un fichier .env factice contenant un faux secret de test.
3. Demandez à l’agent de refactorer le module d’authentification.
4. Vérifiez que :
   • l’agent n’a pas lu le fichier .env factice lors de l’exploration ;
   • aucun token secret n’apparaît dans les journaux d’erreurs, les commentaires ou git diff ;
   • les tests unitaires s’exécutent sans accéder à des fichiers non autorisés.
5. Nettoyez la branche de test une fois les limites validées.

Cette frontière de permissions protège les identifiants tout en conservant une exécution autonome rapide.