Claude Code : interdire l'écriture hors de votre projet avec un seul réglage

Un agent qui édite des fichiers agit avec vos droits, pas avec des droits réduits « pour l'IA ». Si vous lancez Claude Code dans un dossier de projet, rien n'empêche, sans règle explicite, une écriture mal dirigée vers un fichier de configuration du dossier utilisateur ou vers le projet voisin. Depuis la version 2.1.314, il existe un réglage pour poser cette frontière. Cet article explique où le mettre, ce qu'il couvre, et surtout ce qu'il ne couvre pas. Si vous démarrez avec l'outil, le guide complet pour apprendre Claude pose les bases.

En bref :

• Le réglage permissions.blockWritesOutsideWorkingDirectories a été ajouté dans Claude Code 2.1.314, le 30 octobre 2026.
• Il fait refuser aux outils Write, Edit et NotebookEdit les chemins situés hors des dossiers de travail, dans tous les modes de permission.
• Le changelog ne cite que ces trois outils : les commandes Bash ne sont pas documentées comme couvertes.
• Un réglage jumeau, permissions.blockReadsOutsideWorkingDirectories, existe pour la lecture.
• Le test de vérification prend deux minutes : demander volontairement une écriture hors du projet.

Pourquoi limiter Claude Code à votre dossier de travail ?

Parce que la frontière du projet est la première barrière de sécurité : Claude Code lit, écrit et exécute dans vos dossiers locaux avec vos permissions. Le risque vient rarement d'une intention malveillante. Il vient d'un chemin relatif mal interprété, d'un fichier généré au mauvais endroit, d'une commande qui remonte d'un dossier de trop.

Prenons un cas ordinaire. Vous demandez à l'agent de « ranger les fichiers de configuration ». Il en trouve un à la racine de votre dossier personnel, qui ressemble à celui du projet, et le modifie. Rien de dramatique en apparence, jusqu'au jour où ce fichier pilote autre chose que votre projet. Aucune statistique ne mesure la fréquence de ce genre d'accident, et je n'en citerai pas : le point est qu'il est évitable avec une ligne de configuration.

Quel réglage empêche Claude Code d'écrire hors du projet ?

Le réglage s'appelle permissions.blockWritesOutsideWorkingDirectories. Quand il est actif, les outils Write, Edit et NotebookEdit refusent tout chemin situé en dehors des dossiers de travail, quel que soit le mode de permission choisi. Il a été ajouté dans Claude Code 2.1.314, publiée le 30 octobre 2026, selon le changelog officiel.

Le « dossier de travail » est le répertoire où vous lancez Claude Code, auquel s'ajoutent les dossiers supplémentaires déclarés dans additionalDirectories. C'est ce périmètre qui définit ce qui est autorisé.

Une précision d'honnêteté : au 31 octobre 2026, ce réglage n'apparaît pas encore dans la page de référence des settings. Les informations de cet article viennent du changelog de la version 2.1.314. La valeur par défaut n'est pas documentée, donc ne partez pas du principe que le blocage est actif sans l'avoir écrit vous-même. La valeur à utiliser est un booléen, true.

Ce réglage a un jumeau côté lecture, permissions.blockReadsOutsideWorkingDirectories, décrit dans la documentation des permissions. Il fait refuser aux outils de fichiers les chemins hors des dossiers de travail. En mode auto, Claude Code propose de l'activer la première fois que Claude lit hors de ces dossiers.

Comment activer le réglage pas à pas ?

Ajoutez le bloc permissions dans un fichier de settings de Claude Code, avec la valeur true, puis relancez votre session. Le réglage se pose dans les fichiers de settings au niveau utilisateur, projet ou politique gérée.

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true
  }
}

Si vous avez déjà un fichier de settings avec d'autres clés, ne le remplacez pas : ajoutez simplement la clé blockWritesOutsideWorkingDirectories à l'intérieur du bloc permissions existant, en gardant le JSON valide (virgules comprises). Une accolade oubliée et le fichier entier peut être ignoré.

Réglage personnel ou réglage partagé avec l'équipe ?

Posé au niveau utilisateur, le réglage vous protège sur tous vos projets. Posé au niveau du projet, il peut être versionné avec le code et s'applique à toute personne qui travaille sur le dépôt. Pour un projet à plusieurs, le niveau projet évite que chacun configure son poste à sa façon. La documentation officielle des permissions détaille la précédence entre ces niveaux : vérifiez-la dans la version de l'outil que vous utilisez avant de supposer qu'un niveau écrase l'autre.

Si vous découvrez où se rangent ces fichiers de réglages, le tour d'horizon de Claude Code sur la page outil est un bon point d'entrée.

Comment vérifier que le blocage fonctionne vraiment ?

En provoquant un échec : demandez à Claude Code d'écrire un fichier hors du projet, puis dans le projet. La preuve ne se lit pas dans le fichier de configuration, elle se constate par un essai volontaire d'écriture hors périmètre.

Voici le test, qui prend moins de deux minutes :

1. Lancez Claude Code dans le dossier de votre projet, après avoir relancé la session.
2. Demandez-lui de créer un petit fichier texte nommé test-hors-perimetre.txt dans le dossier parent du projet.
3. Observez la réponse : l'écriture doit être refusée.
4. Demandez ensuite la même chose à l'intérieur du projet : cette fois, le fichier doit être créé.
5. Supprimez le fichier de test créé dans le projet.

Je ne cite pas ici de message d'erreur exact : il n'est pas documenté et je n'ai pas relevé celui de votre version. Si le fichier hors périmètre se crée malgré le réglage, vérifiez trois choses : la syntaxe du JSON, le niveau du fichier où vous avez posé la clé, et la version de Claude Code (le réglage n'existe que depuis la 2.1.314).

Que bloque ce réglage, et que laisse-t-il passer ?

Il bloque les écritures faites par les outils Write, Edit et NotebookEdit hors des dossiers de travail. Rien d'autre n'est documenté comme couvert, et c'est le point à retenir pour ne pas se rassurer à tort.

Concrètement, cela laisse deux zones grises :

• Les commandes Bash. Une redirection de type cat > fichier exécutée par l'agent passe par le shell, pas par un outil d'édition. Le changelog ne dit pas que le réglage s'y applique. Pour borner aussi le shell, la documentation renvoie au sandboxing et aux règles de permission ; ne considérez pas que ce réglage seul ferme cette porte.
• La lecture. Interdire l'écriture n'empêche pas l'agent de lire un fichier sensible hors du projet. C'est le rôle du réglage jumeau blockReadsOutsideWorkingDirectories, ou des règles de permission dédiées.

Le sandboxing mérite d'être regardé de près si vous faites tourner l'agent sans surveillance. Les articles sur le sandboxing par domaine et sur le mode restreint pour auditer du code décrivent deux mécanismes complémentaires, avec leurs limites propres. Le second le dit d'ailleurs sans détour : ce n'est pas un sandbox au niveau du système d'exploitation.

Comment combiner ce réglage avec les autres protections de Claude Code ?

En le traitant comme une couche, pas comme une stratégie. Il réduit le risque d'écriture hors périmètre ; il ne réduit pas le risque d'erreur à l'intérieur du projet, ni celui d'une commande shell.

Un empilement raisonnable pour un entrepreneur qui construit seul :

• Un dépôt git. C'est le moyen le plus simple d'annuler une modification indésirable dans le projet. Sans lui, aucun réglage ne vous sauvera d'une mauvaise édition.
• Le système de permissions (autoriser, refuser ou demander confirmation par outil et par commande), qui reste la couche principale. Le mode auto a ses propres garde-fous, détaillés dans l'article sur le mode auto devenu réglage par défaut.
• Une sauvegarde avant les grosses sessions de refonte.
• Un lancement depuis le bon dossier : ne démarrez jamais l'agent à la racine du disque ou dans votre dossier personnel, car c'est ce répertoire qui définit le périmètre.

Pour les équipes qui veulent aller plus loin sur la gouvernance, d'autres réglages gérés existent, comme le verrouillage de modèles décrit dans cet article sur les modèles d'équipe.

Faut-il toujours activer le blocage, ou y a-t-il des cas où l'assouplir ?

Gardez-le actif par défaut. Si un besoin légitime d'écrire ailleurs apparaît, élargissez le périmètre dossier par dossier plutôt que de désactiver le réglage.

Les cas où l'on peut avoir besoin d'écrire hors du dossier de lancement existent : un monorepo où plusieurs applications vivent côte à côte, un répertoire de configuration partagé, un dossier frère où l'on génère des fichiers. Dans ces situations, la bonne approche est de déclarer le dossier supplémentaire dans additionalDirectories, ce qui l'ajoute au périmètre autorisé, plutôt que de couper la protection pour tout le monde. Je n'ai pas de syntaxe plus précise que ce nom de clé à vous donner : consultez la documentation de votre version pour son emplacement exact dans le fichier.

Cette hygiène compte dès qu'on passe du test à un vrai produit. Quand on construit une application avec Claude Code, la page créer une application avec Claude Code sans être développeur montre le chemin complet, et le déploiement avec Vercel et Next.js en fait partie. Le périmètre de fichiers est l'un des premiers réflexes à installer, avant d'avoir un projet qui contient autre chose que des essais.

Questions fréquentes

Passer à la pratique

Ouvrez votre fichier de settings, ajoutez la clé, relancez la session et faites le test de refus : dix minutes en tout, y compris la suppression du fichier de test. Si vous voulez ensuite aller de l'idée à une application en ligne avec des garde-fous posés dès le départ, la formation Construire votre produit IA en 5 semaines déroule ce parcours étape par étape, avec les bons réflexes de sécurité intégrés.