Développement avec l’IA

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

Guide pratique pour limiter les droits de Claude Code : isoler les secrets, encadrer les commandes Git et shell, et vérifier les garde-fous avant tout accès à un dépôt de production.

BetterToken

Équipe éditoriale

20 août 20264 min de lecture

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 :

Ajoutez à .gitignore tous les fichiers d'environnement contenant des secrets.
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.
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](https://docs.bettertoken.ai/ai-tools/claude-code).

---

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

É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.
É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.
É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. 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 :

Créez une branche de test temporaire : git checkout -b test/permission-check.
Ajoutez un fichier .env factice contenant un faux secret de test.
Demandez à l'agent de refactorer le module d'authentification.
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.
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.

Prêt à optimiser votre workflow LLM ?

Connectez vos modèles via une API unique, gérez les clés et maîtrisez vos dépenses d’IA.