36 36
37Avant la v2.1.211, Claude Code enregistrait toujours la règle dans le répertoire de démarrage, donc une approbation accordée dans un worktree ou un sous-répertoire ne s'appliquait pas au reste du référentiel. Les règles que les versions antérieures ont enregistrées dans un sous-répertoire ou un worktree s'appliquent toujours aux sessions démarrées là.37Avant la v2.1.211, Claude Code enregistrait toujours la règle dans le répertoire de démarrage, donc une approbation accordée dans un worktree ou un sous-répertoire ne s'appliquait pas au reste du référentiel. Les règles que les versions antérieures ont enregistrées dans un sous-répertoire ou un worktree s'appliquent toujours aux sessions démarrées là.
38 38
39Parfois, une invite d'autorisation n'offre qu'une approbation unique, sans option « ne pas demander à nouveau » et sans option pour autoriser l'action pour le reste de la session. Claude Code n'offre ces options que lorsque l'invite peut vous montrer tout ce qu'elles autoriseraient, donc une règle que vous enregistrez à partir d'une invite couvre uniquement ce que son option nommée. Lorsqu'une invite n'offre que l'approbation unique, approuvez l'action une fois, ou ajoutez la règle vous-même dans [`/permissions`](#manage-permissions).39Parfois, une demande de permission n'offre qu'une approbation unique, sans option « ne pas demander à nouveau » et sans option pour autoriser l'action pour le reste de la session. Claude Code n'offre ces options que lorsque la demande peut vous montrer tout ce qu'elles autoriseraient, donc une règle que vous enregistrez à partir d'une demande couvre uniquement ce que son option indiquait. Lorsqu'une demande n'offre que l'approbation unique, approuvez l'action une fois, ou ajoutez la règle vous-même dans [`/permissions`](#manage-permissions). Pour ne plus recevoir de demandes pour une commande qui commence par un wrapper d'exécution tel que `watch`, ou pour une commande `find` avec une action telle que `-delete`, consultez [Wrappers d'exécution et actions `find`](#exec-wrappers-and-find-actions).
40 40
41<h3 id="add-a-comment-when-you-answer-a-permission-prompt">41<h3 id="add-a-comment-when-you-answer-a-permission-prompt">
42 Ajouter un commentaire lorsque vous répondez à une invite d'autorisation42 Ajouter un commentaire lorsque vous répondez à une invite d'autorisation
46 46
47Avec le champ ouvert, tapez le commentaire puis appuyez sur l'une de ces touches :47Avec le champ ouvert, tapez le commentaire puis appuyez sur l'une de ces touches :
48 48
49* `Entrée` : soumet votre réponse avec le commentaire joint. Si vous laissez le champ vide, Claude Code soumet la réponse sans commentaire.49* `Enter` : soumet votre réponse avec le commentaire joint. Si vous laissez le champ vide, Claude Code soumet la réponse sans commentaire.
50* `Tab` : ferme le champ sans répondre. Claude Code conserve le texte que vous avez tapé et l'envoie toujours si vous répondez avec cette option.50* `Tab` : ferme le champ sans répondre. Claude Code conserve le texte que vous avez tapé et l'envoie toujours si vous répondez avec cette option.
51* `Maj+Tab` : sur une invite de fichier, comme une invite Édition ou Écriture, ferme le champ de la même manière que `Tab`. Avant la v2.1.235, appuyer sur `Maj+Tab` à l'intérieur du champ sélectionnait plutôt l'option qui autorise l'action pour le reste de la session, donc Claude Code approuvait l'action pour le reste de la session et supprimait le commentaire.51* `Shift+Tab` : sur une demande de fichier, comme une demande Edit ou Write, ferme le champ de la même manière que `Tab`. Avant la v2.1.235, appuyer sur `Shift+Tab` à l'intérieur du champ sélectionnait plutôt l'option qui autorise l'action pour le reste de la session, donc Claude Code approuvait l'action pour le reste de la session et supprimait le commentaire.
52 52
53Claude Code livre le commentaire différemment selon la façon dont vous avez répondu :53Claude Code livre le commentaire différemment selon la façon dont vous avez répondu :
54 54
91| `acceptEdits` | Accepte automatiquement les éditions de fichiers et les commandes courantes du système de fichiers telles que `mkdir`, `touch`, `mv` et `cp` pour les chemins du répertoire de travail ou `additionalDirectories` |91| `acceptEdits` | Accepte automatiquement les éditions de fichiers et les commandes courantes du système de fichiers telles que `mkdir`, `touch`, `mv` et `cp` pour les chemins du répertoire de travail ou `additionalDirectories` |
92| `plan` | Claude lit les fichiers et exécute les commandes shell en lecture seule pour explorer mais n'édite pas vos fichiers source ; avec le [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode) disponible, les commandes approuvées par le classificateur s'exécutent également. Étiqueté Plan dans l'interface de ligne de commande et l'extension VS Code |92| `plan` | Claude lit les fichiers et exécute les commandes shell en lecture seule pour explorer mais n'édite pas vos fichiers source ; avec le [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode) disponible, les commandes approuvées par le classificateur s'exécutent également. Étiqueté Plan dans l'interface de ligne de commande et l'extension VS Code |
93| `auto` | S'exécute sans invites de routine ; avant que des actions telles que les commandes shell et les demandes réseau s'exécutent, un [classificateur](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode) en arrière-plan vérifie qu'elles s'alignent avec votre demande |93| `auto` | S'exécute sans invites de routine ; avant que des actions telles que les commandes shell et les demandes réseau s'exécutent, un [classificateur](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode) en arrière-plan vérifie qu'elles s'alignent avec votre demande |
94| `dontAsk` | Refuse automatiquement chaque appel qui demanderait autrement une autorisation ; les lectures de fichiers dans vos répertoires de travail et autres actions qui ne nécessitent aucune approbation s'exécutent toujours, tout comme les outils pré-approuvés via `/permissions` ou les règles `permissions.allow`. `AskUserQuestion`, les outils MCP marqués [`requiresUserInteraction`](/docs/fr/mcp#require-approval-for-a-specific-tool), et les outils connecteur [que votre organisation a définis sur `ask`](/docs/fr/mcp#organization-controls-on-connector-tools) dans les sessions où ce paramètre atteint Claude Code sont refusés même si vous les avez autorisés |94| `dontAsk` | Refuse automatiquement chaque appel qui demanderait autrement une permission ; les lectures de fichiers dans vos répertoires de travail et autres actions qui ne nécessitent aucune approbation s'exécutent toujours, tout comme les outils pré-approuvés via `/permissions` ou les règles `permissions.allow`. `AskUserQuestion`, les outils MCP marqués [`requiresUserInteraction`](/docs/fr/mcp#require-approval-for-a-specific-tool), [les lectures depuis des chemins réseau](#network-paths), et les outils connecteur [que votre organisation a définis sur `ask`](/docs/fr/mcp#organization-controls-on-connector-tools) dans les sessions où ce paramètre atteint Claude Code sont refusés même si vous les avez autorisés |
95| `bypassPermissions` | Ignore les invites d'autorisation, sauf pour les [actions qu'aucun mode n'approuve automatiquement](/docs/fr/permission-modes#actions-no-mode-auto-approves) |95| `bypassPermissions` | Ignore les invites d'autorisation, sauf pour les [actions qu'aucun mode n'approuve automatiquement](/docs/fr/permission-modes#actions-no-mode-auto-approves) |
96 96
97<Warning>97<Warning>
233L'étiquette affichée pour un outil dans la transcription et la boîte de dialogue d'autorisation peut différer de son nom canonique. Par exemple, l'outil étiqueté `Stop Task` dans la transcription a le nom canonique `TaskStop`. Les règles d'autorisation et les [correspondances de hook](/docs/fr/hooks) ne correspondent pas à l'étiquette, donc une règle écrite comme `Stop Task` ne correspond pas. Pour les règles de refus et de demande, l'avertissement au démarrage ci-dessus détecte l'inadéquation. Utilisez les noms canoniques listés dans la [référence des outils](/docs/fr/tools-reference).233L'étiquette affichée pour un outil dans la transcription et la boîte de dialogue d'autorisation peut différer de son nom canonique. Par exemple, l'outil étiqueté `Stop Task` dans la transcription a le nom canonique `TaskStop`. Les règles d'autorisation et les [correspondances de hook](/docs/fr/hooks) ne correspondent pas à l'étiquette, donc une règle écrite comme `Stop Task` ne correspond pas. Pour les règles de refus et de demande, l'avertissement au démarrage ci-dessus détecte l'inadéquation. Utilisez les noms canoniques listés dans la [référence des outils](/docs/fr/tools-reference).
234 234
235<h2 id="tool-specific-permission-rules">235<h2 id="tool-specific-permission-rules">
236 Règles d'autorisation spécifiques aux outils236 Règles de permission spécifiques aux outils
237</h2>237</h2>
238 238
239<h3 id="bash">239<h3 id="bash">
240 Bash240 Bash
241</h3>241</h3>
242 242
243Les règles Bash correspondent à l'ensemble du texte de la commande, avec `*` représentant n'importe quel texte. [Les modèles de caractères génériques](#wildcard-patterns) montrent quelles commandes chaque forme de règle correspond et où placer le `*`. Le reste de cette section couvre comment Claude Code correspond aux commandes composées et aux wrappers, ce qu'une règle ne correspond pas, les commandes en lecture seule et les redirections.243Les règles Bash correspondent au texte complet de la commande, `*` représentant n'importe quel texte. [Modèles avec caractères génériques](#wildcard-patterns) indique quelles commandes chaque forme de règle fait correspondre et où placer le `*`. Le reste de cette section explique comment Claude Code fait correspondre les commandes composées et les wrappers, quels wrappers et quelles actions `find` une règle de préfixe ne peut pas approuver, ce qu'une règle ne fait pas correspondre, les commandes en lecture seule et les redirections.
244 244
245<h4 id="compound-commands">245<h4 id="compound-commands">
246 Commandes composées246 Commandes composées
247</h4>247</h4>
248 248
249<Tip>249<Tip>
250 Claude Code est conscient des opérateurs shell, donc une règle comme `Bash(safe-cmd *)` ne lui donnera pas la permission d'exécuter la commande `safe-cmd && other-cmd`. Les séparateurs de commande reconnus sont `&&`, `||`, `;`, `|`, `|&`, `&` et les sauts de ligne. Une règle doit correspondre à chaque sous-commande indépendamment.250 Claude Code connaît les opérateurs du shell. Une règle comme `Bash(safe-cmd *)` ne lui donne donc pas la permission d'exécuter la commande `safe-cmd && other-cmd`. Les séparateurs de commandes reconnus sont `&&`, `||`, `;`, `|`, `|&`, `&` et les sauts de ligne. Une règle doit correspondre à chaque sous-commande indépendamment.
251</Tip>251</Tip>
252 252
253Les règles de refus et de demande s'appliquent lorsqu'une sous-commande les correspond, y compris une commande imbriquée à l'intérieur d'une sous-coquille, une substitution de commande ou un corps de contrôle de flux tel qu'une boucle `for`. Une règle de demande comme `Bash(git clean *)` vous invite toujours pour `cd /tmp && git clean -f` ou `echo "$(git clean -f)"`, même en [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode).253Les règles deny et ask s'appliquent dès qu'une sous-commande leur correspond, y compris une commande imbriquée dans un sous-shell, une substitution de commande ou le corps d'une structure de contrôle comme une boucle `for`. Une règle ask comme `Bash(git clean *)` vous demande toujours une confirmation pour `cd /tmp && git clean -f` ou `echo "$(git clean -f)"`, même en [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode).
254 254
255Lorsque `&&` ou `||` n'a rien après lui, comme dans `npm test &&`, Claude Code traite la commande comme non analysable et ne la divise pas en sous-commandes pour la correspondance des règles d'autorisation, donc une règle telle que `Bash(npm *)` ne l'approuve pas.255Lorsque `&&` ou `||` n'est suivi de rien, comme dans `npm test &&`, Claude Code considère la commande comme impossible à analyser et ne la divise pas en sous-commandes pour la correspondance avec les règles allow. Une règle comme `Bash(npm *)` ne l'approuve donc pas.
256 256
257Lorsque vous approuvez une commande composée avec « Oui, ne pas demander à nouveau », Claude Code enregistre une règle séparée pour chaque sous-commande qui nécessite une approbation, plutôt qu'une seule règle pour la chaîne composée complète. Par exemple, approuver `git status && npm test` enregistre une règle pour `npm test`, donc les invocations futures de `npm test` sont reconnues indépendamment de ce qui précède le `&&`. Les sous-commandes comme `cd` dans un répertoire en dehors de vos répertoires de travail génèrent leur propre règle Read pour ce chemin. Jusqu'à 5 règles peuvent être enregistrées pour une seule commande composée.257Lorsque vous approuvez une commande composée avec « Yes, and don't ask again », Claude Code enregistre une règle distincte pour chaque sous-commande nécessitant une approbation, plutôt qu'une règle unique pour la chaîne composée complète. Par exemple, approuver `git status && npm test` enregistre une règle pour `npm test`, de sorte que les invocations futures de `npm test` sont reconnues quel que soit ce qui précède le `&&`. Les sous-commandes comme un `cd` vers un répertoire situé en dehors de vos répertoires de travail génèrent leur propre règle Read pour ce chemin. Jusqu'à 5 règles peuvent être enregistrées pour une seule commande composée.
258 258
259<h4 id="process-wrappers">259<h4 id="process-wrappers">
260 Wrappers260 Wrappers
261</h4>261</h4>
262 262
263Avant de correspondre aux règles Bash, Claude Code supprime un ensemble fixe de wrappers, donc une règle comme `Bash(npm test *)` correspond également à `timeout 30 npm test`. Les wrappers supprimés sont `timeout`, `time`, `nice`, `nohup` et `stdbuf`, plus les builtins shell `command` et `builtin`, et `noglob` de zsh. Chacun exécute son argument comme la commande réelle. Deux formes connexes ne sont pas supprimées : la forme de requête `command -v`, qui recherche une commande plutôt que de l'exécuter, et `nocorrect` de zsh.263Avant de faire correspondre les règles Bash, Claude Code supprime un ensemble fixe de wrappers. Une règle comme `Bash(npm test *)` correspond donc aussi à `timeout 30 npm test`. Les wrappers supprimés sont `timeout`, `time`, `nice`, `nohup` et `stdbuf`, ainsi que les builtins du shell `command` et `builtin`, et `noglob` de zsh. Chacun exécute son argument comme la commande réelle. Deux formes apparentées ne sont pas supprimées : la forme de requête `command -v`, qui recherche une commande au lieu d'en exécuter une, et `nocorrect` de zsh.
264 264
265Claude Code supprime également une affectation initiale de certaines variables d'environnement connues comme sûres, donc `Bash(npm test *)` correspond à `NODE_ENV=test npm test`. Une règle d'autorisation ne correspondra pas au-delà d'une affectation de toute autre variable. Une règle de refus ou de demande correspond au-delà de toute affectation initiale, donc `Bash(rm *)` en refus correspond toujours à `FOO=bar rm -rf tmp/`.265Claude Code supprime également une affectation initiale de certaines variables d'environnement connues comme sûres, de sorte que `Bash(npm test *)` correspond à `NODE_ENV=test npm test`. Une règle allow ne fait pas de correspondance au-delà d'une affectation de toute autre variable. Une règle deny ou ask fait correspondre au-delà de toute affectation initiale, de sorte que `Bash(rm *)` dans deny correspond toujours à `FOO=bar rm -rf tmp/`.
266 266
267Le `xargs` nu est également supprimé, donc `Bash(grep *)` correspond à `xargs grep pattern`. La suppression s'applique uniquement lorsque `xargs` n'a pas de drapeaux : une invocation comme `xargs -n1 grep pattern` est mise en correspondance en tant que commande `xargs`, donc les règles écrites pour la commande interne ne la couvrent pas.267Un `xargs` nu est également supprimé, de sorte que `Bash(grep *)` correspond à `xargs grep pattern`. La suppression ne s'applique que lorsque `xargs` n'a aucun flag : une invocation comme `xargs -n1 grep pattern` est traitée comme une commande `xargs`, et les règles écrites pour la commande interne ne la couvrent pas.
268 268
269Cette liste de wrappers est intégrée et n'est pas configurable. Les exécuteurs d'environnement de développement tels que `direnv exec`, `devbox run`, `mise exec`, `npx` et `docker exec` ne figurent pas dans la liste. Parce que ces outils exécutent leurs arguments en tant que commande, une règle comme `Bash(devbox run *)` correspond à tout ce qui vient après `run`, y compris `devbox run rm -rf .`. Pour approuver le travail à l'intérieur d'un exécuteur d'environnement, écrivez une règle spécifique qui inclut à la fois l'exécuteur et la commande interne, comme `Bash(devbox run npm test)`. Ajoutez une règle par commande interne que vous souhaitez autoriser.269Cette liste de wrappers est intégrée et n'est pas configurable. Les exécuteurs d'environnements de développement comme `direnv exec`, `devbox run`, `mise exec`, `npx` et `docker exec` ne figurent pas dans la liste. Comme ces outils exécutent leurs arguments en tant que commande, une règle comme `Bash(devbox run *)` correspond à tout ce qui suit `run`, y compris `devbox run rm -rf .`. Pour approuver du travail à l'intérieur d'un exécuteur d'environnement, écrivez une règle spécifique qui inclut à la fois l'exécuteur et la commande interne, comme `Bash(devbox run npm test)`. Ajoutez une règle par commande interne que vous souhaitez autoriser.
270 270
271Les wrappers exec tels que `watch`, `setsid`, `ionice` et `flock` ne peuvent pas être approuvés automatiquement par une règle de préfixe comme `Bash(watch *)`, donc en mode Manuel ils demandent toujours. Il en va de même pour `find` avec `-exec` ou `-delete` : une règle `Bash(find *)` ne couvre pas ces formes. Pour approuver une invocation spécifique, écrivez une règle de correspondance exacte pour la chaîne de commande complète.271<h4 id="exec-wrappers-and-find-actions">
272 Wrappers d'exécution et actions `find`
273</h4>
274
275Une règle de préfixe comme `Bash(watch *)` ou `Bash(find *)` ne peut pas approuver automatiquement les commandes suivantes. En mode Manual, elles déclenchent donc une demande de permission :
276
277* **Wrappers d'exécution** : comme `watch`, `setsid`, `ionice` et `flock`
278* **`find`** : avec une action qui exécute des commandes, supprime des fichiers ou écrit des fichiers, comme `-exec`, `-delete` ou `-fprint`, ou avec `-files0-from`, qui lit dans un fichier les chemins à rechercher
279
280Pour approuver une invocation spécifique qui ne contient pas de `*`, écrivez une règle de correspondance exacte pour la chaîne de commande complète, comme `Bash(find build -type f -delete)`.
281
282Lorsque la commande contient un `*`, comme dans `find . -name '*.tmp' -delete`, Claude Code interprète la règle comme un [modèle avec caractères génériques](#wildcard-patterns), et non comme une correspondance exacte, de sorte que la commande déclenche toujours une demande. Approuvez-la à chaque demande, ou utilisez un [hook PreToolUse](/docs/fr/hooks#pretooluse-decision-control) qui renvoie `"allow"` pour celle-ci.
272 283
273<h4 id="bash-rule-limits">284<h4 id="bash-rule-limits">
274 Ce qu'une règle Bash ne correspond pas285 Ce qu'une règle Bash ne fait pas correspondre
275</h4>286</h4>
276 287
277Une règle Bash correspond au texte de la commande que Claude écrit, après que Claude Code divise les [commandes composées](#compound-commands) et supprime les [wrappers](#process-wrappers). Elle ne correspond pas au même programme invoqué sous une forme différente, donc une règle de refus ou de demande couvre l'invocation que Claude produit généralement et n'est pas une limite de sécurité autour du programme. Ces règles en `deny` ou `ask` arrêtent la première forme et pas les autres :288Une règle Bash correspond au texte de la commande écrite par Claude, après que Claude Code a divisé les [commandes composées](#compound-commands) et supprimé les [wrappers](#process-wrappers). Elle ne fait pas correspondre le même programme invoqué sous une autre forme. Une règle deny ou ask couvre donc l'invocation que Claude produit habituellement et ne constitue pas une frontière de sécurité autour du programme. Placées dans `deny` ou `ask`, ces règles arrêtent la première forme, mais pas les autres :
278 289
279| Règle | Arrête | N'arrête pas |290| Règle | Arrête | N'arrête pas |
280| :- | :- | :- |291| :- | :- | :- |
282| `Bash(rm *)` | `rm -rf build/` | `/bin/rm -rf build/`, `bash -c 'rm -rf build/'` |293| `Bash(rm *)` | `rm -rf build/` | `/bin/rm -rf build/`, `bash -c 'rm -rf build/'` |
283| `Bash(git push *)` | `git push origin main` | `git -C . push origin main`, `git -c push.default=current push origin main`, `git 'push' origin main` |294| `Bash(git push *)` | `git push origin main` | `git -C . push origin main`, `git -c push.default=current push origin main`, `git 'push' origin main` |
284 295
285Vos autres règles et le mode d'autorisation décident les commandes dans la dernière colonne.296Vos autres règles et le mode de permission décident du sort des commandes de la dernière colonne.
286 297
287Pour l'application du système de fichiers et du réseau qui ne dépend pas du texte de la commande, utilisez le [sandboxing](/docs/fr/sandboxing). Pour inspecter le texte de commande complet avec votre propre logique avant son exécution, utilisez un hook [PreToolUse](#extend-permissions-with-hooks).298Pour une application au niveau du système de fichiers et du réseau qui ne dépend pas du texte de la commande, utilisez le [sandboxing](/docs/fr/sandboxing). Pour inspecter le texte complet de la commande avec votre propre logique avant son exécution, utilisez un [hook PreToolUse](#extend-permissions-with-hooks).
288 299
289<h4 id="read-only-commands">300<h4 id="read-only-commands">
290 Commandes en lecture seule301 Commandes en lecture seule
291</h4>302</h4>
292 303
293Claude Code reconnaît un ensemble intégré de commandes Bash comme étant en lecture seule et les exécute sans invite d'autorisation dans tous les modes, sauf pour un chemin que [`permissions.blockReadsOutsideWorkingDirectories`](/docs/fr/settings-reference#permissions-blockreadsoutsideworkingdirectories) protège. L'ensemble inclut `ls`, `cat`, `echo`, `pwd`, `head`, `tail`, `grep`, `find`, `wc`, `which`, `diff`, `stat`, `du`, `cd` et les formes en lecture seule de `git`. L'ensemble n'est pas configurable ; pour exiger une invite pour l'une de ces commandes, ajoutez une règle `ask` ou `deny` pour celle-ci. En mode auto, ces commandes peuvent également attendre l'examen du classificateur ; voir [comment le classificateur évalue les actions](/docs/fr/permission-modes#how-the-classifier-evaluates-actions).304Claude Code reconnaît un ensemble intégré de commandes Bash comme étant en lecture seule et les exécute sans demande de permission dans tous les modes, sauf dans la mesure où [`permissions.blockReadsOutsideWorkingDirectories`](/docs/fr/settings-reference#permissions-blockreadsoutsideworkingdirectories) modifie ce comportement pour les chemins situés en dehors de vos répertoires de travail. L'ensemble comprend `ls`, `cat`, `echo`, `pwd`, `head`, `tail`, `grep`, `find`, `wc`, `which`, `diff`, `stat`, `du`, `cd` et les formes en lecture seule de `git`. L'ensemble n'est pas configurable ; pour exiger une demande pour l'une de ces commandes, ajoutez une règle `ask` ou `deny` pour celle-ci. En mode auto, ces commandes peuvent aussi attendre l'examen du classifieur ; consultez [comment le classifieur évalue les actions](/docs/fr/permission-modes#how-the-classifier-evaluates-actions).
294 305
295Une redirection telle que `ls > out.txt` ajoute une vérification sur la cible. Voir [Redirections](#redirections).306Une redirection comme `ls > out.txt` ajoute une vérification de la cible. Consultez [Redirections](#redirections).
296 307
297Les modèles glob non cités sont autorisés pour les commandes dont chaque drapeau est en lecture seule, donc `ls *.ts` et `wc -l src/*.py` s'exécutent sans invite.308Les motifs glob sans guillemets sont autorisés pour les commandes dont tous les flags sont en lecture seule, de sorte que `ls *.ts` et `wc -l src/*.py` s'exécutent sans demande.
298 309
299En mode Manuel, les commandes de cet ensemble demandent toujours dans ces cas :310En mode Manual, les commandes de cet ensemble déclenchent tout de même une demande dans les cas suivants :
300 311
301* **Globs non cités pour les commandes avec drapeaux capables d'écriture** : les commandes avec des drapeaux capables d'écriture ou d'exécution, tels que `find`, `sort`, `sed` et `git`, demandent lorsqu'un glob non cité est présent, car le glob pourrait s'étendre à un drapeau comme `-delete`.312* **Globs sans guillemets pour les commandes avec des flags capables d'écrire** : les commandes dotées de flags capables d'écrire ou d'exécuter, comme `find`, `sort`, `sed` et `git`, déclenchent une demande en présence d'un glob sans guillemets, car le glob pourrait s'étendre en un flag comme `-delete`.
302* **`docker` pointant vers un autre daemon** : les formes en lecture seule de `docker` demandent lorsque la commande porte un drapeau qui sélectionne un daemon différent, tel que `-H`, `--context` ou `--url` et `--connection` de Podman.313* **`docker` pointant vers un autre daemon** : les formes en lecture seule de `docker` déclenchent une demande lorsque la commande comporte un flag qui sélectionne un autre daemon, comme `-H`, `--context`, ou `--url` et `--connection` de Podman.
303* **`file` avec des drapeaux d'ouverture de chemin** : `file` demande lorsqu'il passe `-m`/`--magic-file` ou `-f`/`--files-from`, car ces drapeaux font que `file` ouvre les chemins nommés dans la valeur du drapeau.314* **`file` avec des flags qui ouvrent des chemins** : `file` déclenche une demande lorsqu'il reçoit `-m`/`--magic-file` ou `-f`/`--files-from`, car ces flags font ouvrir à `file` les chemins nommés dans la valeur du flag.
304* **Chemins réseau sur Windows** : une commande dont les arguments incluent un chemin réseau (UNC), tel que `\\server\share\file`, demande car l'accès à un chemin réseau peut envoyer vos identifiants Windows à l'hôte qu'il nomme. La même vérification s'applique aux commandes de l'[outil PowerShell](/docs/fr/tools-reference#powershell-tool).315* **`ps` susceptible d'afficher des variables d'environnement** : `ps` déclenche une demande lorsque l'un de ses arguments pourrait agir comme l'option `e`, comme dans `ps auxe` ou `ps aux -e`, car cette option affiche les variables d'environnement des processus. `ps aux` et `ps -ef` s'exécutent sans demande. La vérification des formes avec tiret comme `ps aux -e` nécessite Claude Code v2.1.290 ou ultérieur.
305* **Écritures vers des variables shell spéciales** : une commande qui définit, annule ou boucle sur certaines variables shell spéciales, telles que `PATH` ou `IFS`, demande même lorsque le reste de la commande est en lecture seule.316* **Chemins réseau sous Windows** : une commande dont les arguments incluent un chemin réseau (UNC), comme `\\server\share\file`, déclenche une demande, car l'accès à un chemin réseau peut envoyer vos identifiants Windows à l'hôte qu'il désigne. La même vérification s'applique aux commandes de l'[outil PowerShell](/docs/fr/tools-reference#powershell-tool).
306* **Commandes que l'analyse ne peut pas analyser** : lorsque Claude Code ne peut pas analyser complètement une commande, il demande une approbation au lieu de traiter la commande comme en lecture seule. Les commandes plus longues que 10 000 caractères demandent toujours car elles dépassent ce que l'analyse analyse.317* **Écritures dans des variables spéciales du shell** : une commande qui définit, supprime ou parcourt certaines variables spéciales du shell, comme `PATH` ou `IFS`, déclenche une demande même lorsque le reste de la commande est en lecture seule.
318* **Commandes que l'analyse ne peut pas interpréter** : lorsque Claude Code ne parvient pas à analyser entièrement une commande, il demande une approbation au lieu de considérer la commande comme étant en lecture seule. Les commandes de plus de 10 000 caractères déclenchent toujours une demande, car elles dépassent ce que l'analyse prend en charge.
307 319
308Un `cd` dans un chemin à l'intérieur de votre répertoire de travail ou d'un [répertoire supplémentaire](#working-directories) est également en lecture seule, et une commande composée comme `cd packages/api && ls` s'exécute sans invite lorsque chaque partie se qualifie seule. Ces combinaisons demandent même lorsque chaque partie est en lecture seule :320Un `cd` vers un chemin situé dans votre répertoire de travail ou dans un [répertoire supplémentaire](#working-directories) est également en lecture seule, et une commande composée comme `cd packages/api && ls` s'exécute sans demande lorsque chaque partie remplit les conditions à elle seule. Les combinaisons suivantes déclenchent une demande même lorsque chaque partie est en lecture seule :
309 321
310* **`cd` avec `git`** : demande lorsque le `cd` change dans un répertoire différent, car exécuter `git` dans un nouveau répertoire peut exécuter les hooks de ce répertoire. Un `cd` dont la cible se résout au répertoire de travail courant est une non-opération et ne déclenche pas l'invite.322* **`cd` avec `git`** : déclenche une demande lorsque le `cd` passe dans un autre répertoire, car exécuter `git` dans un nouveau répertoire peut exécuter les hooks de ce répertoire. Un `cd` dont la cible correspond au répertoire de travail actuel n'a aucun effet et ne déclenche pas de demande.
311* **`cd` avec une redirection** : demande lorsque Claude Code ne peut pas déterminer le répertoire dans lequel la cible de redirection se résout après l'exécution de `cd`. Une commande dont la seule cible de redirection est `/dev/null`, telle que `cd app; grep -r pattern . 2>/dev/null`, ne demande pas, car `/dev/null` ne dépend pas du répertoire de travail.323* **`cd` avec une redirection** : déclenche une demande lorsque Claude Code ne peut pas déterminer par rapport à quel répertoire la cible de la redirection est résolue après l'exécution du `cd`. Une commande dont la seule cible de redirection est `/dev/null`, comme `cd app; grep -r pattern . 2>/dev/null`, ne déclenche pas de demande, car `/dev/null` ne dépend pas du répertoire de travail.
312 324
313<Warning>325<Warning>
314 Les modèles d'autorisation Bash qui tentent de contraindre les arguments de commande sont fragiles. Par exemple, `Bash(curl http://github.com/ *)` a l'intention de restreindre curl aux URL GitHub, mais ne correspondra pas aux variations comme :326 Les modèles de permission Bash qui tentent de restreindre les arguments des commandes sont fragiles. Par exemple, `Bash(curl http://github.com/ *)` vise à limiter curl aux URL GitHub, mais ne correspondra pas à des variantes comme :
315 327
316 * Options avant l'URL : `curl -X GET http://github.com/...`328 * Options avant l'URL : `curl -X GET http://github.com/...`
317 * Protocole différent : `curl https://github.com/...`329 * Protocole différent : `curl https://github.com/...`
318 * Redirections : `curl -L http://short.example.com/xyz`, qui redirige vers GitHub330 * Redirections : `curl -L http://short.example.com/xyz`, qui redirige vers GitHub
319 * Variables : `URL=http://github.com && curl $URL`331 * Variables : `URL=http://github.com && curl $URL`
320 332
321 Pour un filtrage d'URL plus fiable, envisagez :333 Pour un filtrage d'URL plus fiable, envisagez les options suivantes :
322 334
323 * **Restreindre les outils réseau Bash** : utilisez les règles de refus pour bloquer `curl`, `wget` et les commandes similaires, puis utilisez l'outil WebFetch avec l'autorisation `WebFetch(domain:github.com)` pour les domaines autorisés. Une règle de refus ne correspond pas au même programme par chemin ou à l'intérieur de `sh -c`, donc associez-la à la [liste d'autorisation du réseau sandbox](/docs/fr/sandboxing#network-isolation) lorsque la restriction doit tenir ; voir [ce qu'une règle Bash ne correspond pas](#bash-rule-limits)335 * **Restreindre les outils réseau de Bash** : utilisez des règles deny pour bloquer `curl`, `wget` et les commandes similaires, puis utilisez l'outil WebFetch avec la permission `WebFetch(domain:github.com)` pour les domaines autorisés. Une règle deny ne fait pas correspondre le même programme invoqué par son chemin ou à l'intérieur de `sh -c` ; associez-la donc à la [liste d'autorisation réseau du sandbox](/docs/fr/sandboxing#network-isolation) lorsque la restriction doit être garantie. Consultez [ce qu'une règle Bash ne fait pas correspondre](#bash-rule-limits)
324 * **Utiliser les hooks PreToolUse** : implémentez un hook qui valide les URL dans les commandes Bash et bloque les domaines non autorisés336 * **Utiliser des hooks PreToolUse** : implémentez un hook qui valide les URL dans les commandes Bash et bloque les domaines non autorisés
325 * **Ajouter des conseils CLAUDE.md** : décrivez vos modèles curl autorisés dans `CLAUDE.md`. Cela façonne ce que Claude essaie mais n'applique pas une limite, donc associez-le à l'une des options ci-dessus337 * **Ajouter des consignes dans CLAUDE.md** : décrivez vos modèles curl autorisés dans `CLAUDE.md`. Cela oriente ce que Claude tente de faire, mais n'impose aucune limite ; associez-le donc à l'une des options ci-dessus
326 338
327 Notez que l'utilisation de WebFetch seul n'empêche pas l'accès au réseau. Si Bash est autorisé, Claude peut toujours utiliser `curl`, `wget` ou d'autres outils pour atteindre n'importe quelle URL.339 Notez que l'utilisation de WebFetch seul n'empêche pas l'accès au réseau. Si Bash est autorisé, Claude peut toujours utiliser `curl`, `wget` ou d'autres outils pour atteindre n'importe quelle URL.
328</Warning>340</Warning>
331 Redirections343 Redirections
332</h4>344</h4>
333 345
334Lorsqu'une commande redirige la sortie ou l'entrée, Claude Code vérifie la cible de redirection par rapport à vos règles de fichier comme si Claude avait écrit ou lu ce fichier directement :346Lorsqu'une commande redirige une sortie ou une entrée, Claude Code vérifie la cible de la redirection par rapport à vos règles de fichiers, comme si Claude écrivait ou lisait ce fichier directement :
335 347
336* **Redirections de sortie** : pour `> file`, `>> file` ou `2> file`, la vérification couvre vos règles d'autorisation et de refus `Edit`, les [chemins protégés](/docs/fr/permission-modes#protected-paths) et les [répertoires de travail](#working-directories). Une règle telle que `Bash(git commit *)` autorise la commande, pas la cible. Une cible qui commence par `~` ou contient un caractère glob nécessite votre approbation.348* **Redirections de sortie** : pour `> file`, `>> file` ou `2> file`, la vérification couvre vos règles `Edit` allow et deny, les [chemins protégés](/docs/fr/permission-modes#protected-paths) et les [répertoires de travail](#working-directories). Une règle comme `Bash(git commit *)` autorise la commande, pas la cible. Une cible qui commence par `~` ou contient un caractère glob nécessite votre approbation.
337* **Redirections d'entrée** : pour `< file`, la vérification couvre vos règles d'autorisation et de refus `Read` et les répertoires de travail. Une cible en dehors des répertoires de travail nécessite votre approbation sauf si une règle d'autorisation la couvre. Une cible qui contient un modèle glob ou un chemin relatif qui suit un `cd` dans la même commande nécessite votre approbation même lorsqu'une règle d'autorisation la couvre. Claude Code vérifie les cibles d'entrée en v2.1.257 et ultérieur.349* **Redirections d'entrée** : pour `< file`, la vérification couvre vos règles `Read` allow et deny ainsi que les répertoires de travail. Une cible située en dehors des répertoires de travail nécessite votre approbation, sauf si une règle allow la couvre. Une cible qui contient un motif glob, ou un chemin relatif qui suit un `cd` dans la même commande, nécessite votre approbation même lorsqu'une règle allow la couvre. Claude Code vérifie les cibles d'entrée à partir de la v2.1.257.
338 350
339Les cibles sans fichier derrière elles ne sont pas vérifiées : `/dev/null`, les formes de descripteur de fichier telles que `2>&1` et `<&3`, et les here-docs et here-strings.351Les cibles qui ne correspondent à aucun fichier ne sont pas vérifiées : `/dev/null`, les formes de descripteur de fichier comme `2>&1` et `<&3`, ainsi que les here-docs et here-strings.
340 352
341Claude Code vérifie également les fichiers qu'une commande `tee` écrit, y compris dans un pipeline tel que `make | tee build.log`. La vérification couvre vos règles d'autorisation et de refus `Edit`, les [chemins protégés](/docs/fr/permission-modes#protected-paths) et les [répertoires de travail](#working-directories). Une règle d'autorisation telle que `Bash(tee *)` ne couvre pas une destination en dehors des répertoires de travail. Claude Code vérifie les cibles `tee` en v2.1.269 et ultérieur.353Claude Code vérifie également les fichiers qu'écrit une commande `tee`, y compris dans un pipeline comme `make | tee build.log`. La vérification couvre vos règles `Edit` allow et deny, les [chemins protégés](/docs/fr/permission-modes#protected-paths) et les [répertoires de travail](#working-directories). Une règle allow comme `Bash(tee *)` ne couvre pas une destination située en dehors des répertoires de travail. Claude Code vérifie les cibles de `tee` à partir de la v2.1.269.
342 354
343<h3 id="powershell">355<h3 id="powershell">
344 PowerShell356 PowerShell
345</h3>357</h3>
346 358
347Les règles d'autorisation PowerShell utilisent la même forme que les règles Bash. Les caractères génériques avec `*` correspondent à n'importe quelle position, le suffixe `:*` est équivalent à un ` *` de fin, et un `PowerShell` nu ou `PowerShell(*)` correspond à chaque commande. Cette configuration permet les commandes `Get-ChildItem` et `git commit` tout en bloquant `Remove-Item` :359Les règles de permission PowerShell ont la même forme que les règles Bash. Les caractères génériques `*` correspondent à n'importe quelle position, le suffixe `:*` équivaut à un ` *` final, et un `PowerShell` ou `PowerShell(*)` nu correspond à toutes les commandes. Cette configuration autorise les commandes `Get-ChildItem` et `git commit` tout en bloquant `Remove-Item` :
348 360
349```json theme={null}361```json theme={null}
350{362{
360}372}
361```373```
362 374
363Les alias courants sont canonicalisés avant la correspondance. Une règle écrite pour le nom de la cmdlet correspond également à ses alias, donc `PowerShell(Get-ChildItem *)` correspond à `gci`, `ls` et `dir` aussi. La correspondance est insensible à la casse.375Les alias courants sont normalisés avant la correspondance. Une règle écrite pour le nom de la cmdlet correspond aussi à ses alias, de sorte que `PowerShell(Get-ChildItem *)` correspond également à `gci`, `ls` et `dir`. La correspondance ne tient pas compte de la casse.
364 376
365Claude Code analyse l'AST PowerShell et vérifie chaque commande dans une commande composée indépendamment. Les opérateurs de pipeline `|`, les séparateurs d'instruction `;` et sur PowerShell 7+ les opérateurs de chaîne `&&` et `||` divisent une commande composée en sous-commandes. Une règle doit correspondre à chaque sous-commande pour que la commande composée soit autorisée.377Claude Code analyse l'AST PowerShell et vérifie indépendamment chaque commande d'une commande composée. Les opérateurs de pipeline `|`, les séparateurs d'instructions `;` et, sur PowerShell 7+, les opérateurs de chaînage `&&` et `||` divisent une commande composée en sous-commandes. Une règle doit correspondre à chaque sous-commande pour que la commande composée soit autorisée.
366 378
367<h3 id="read-and-edit">379<h3 id="read-and-edit">
368 Read et Edit380 Read et Edit
369</h3>381</h3>
370 382
371Pour bloquer les outils de fichier de Claude de lire un fichier ou un répertoire, ajoutez une règle de refus `Read` pour son chemin, telle que `Read(./.env)` ou `Read(./secrets/**)` ; [Exclure les fichiers sensibles](/docs/fr/settings-reference#exclude-sensitive-files) a un exemple prêt à coller. Si votre projet contient un fichier `.claudeignore`, celui-ci n'a aucun effet ; déplacez donc ses entrées dans des règles de refus `Read`.383Pour empêcher les outils de fichiers de Claude de lire un fichier ou un répertoire, ajoutez une règle `Read` deny pour son chemin, comme `Read(./.env)` ou `Read(./secrets/**)` ; [Exclure les fichiers sensibles](/docs/fr/settings-reference#exclude-sensitive-files) propose un exemple prêt à coller. Si votre projet contient un fichier `.claudeignore`, celui-ci n'a aucun effet ; déplacez donc ses entrées dans des règles `Read` deny.
372 384
373Les règles `Edit` s'appliquent à tous les outils intégrés qui éditent les fichiers. Claude fait un effort raisonnable pour appliquer les règles `Read` à tous les outils intégrés qui lisent les fichiers comme Grep et Glob, aux mentions `@file` dans vos invites et à la sélection et au contexte de fichier ouvert qu'un [IDE](/docs/fr/vs-code#the-built-in-ide-mcp-server) connecté partage avec Claude.385Les règles `Edit` s'appliquent à tous les outils intégrés qui modifient des fichiers. Claude s'efforce d'appliquer les règles `Read` à tous les outils intégrés qui lisent des fichiers, comme Grep et Glob, aux mentions `@file` dans vos prompts, ainsi qu'à la sélection et au contexte des fichiers ouverts qu'un [IDE](/docs/fr/vs-code#the-built-in-ide-mcp-server) connecté partage avec Claude.
374 386
375Une règle de refus `Read` bloque également les [outils Edit et Write](/docs/fr/errors#file-is-covered-by-a-read-deny-rule) sur le même chemin, y compris la création d'un nouveau fichier là-bas. NotebookEdit n'est pas couvert, donc ajoutez une règle de refus `Edit` pour les chemins qu'aucun outil ne peut modifier. La vérification nécessite Claude Code v2.1.208 ou ultérieur sur les éditions, et v2.1.228 ou ultérieur sur les écritures.387Une règle `Read` deny bloque également les [outils Edit et Write](/docs/fr/errors#file-is-covered-by-a-read-deny-rule) sur le même chemin, y compris la création d'un nouveau fichier à cet emplacement. NotebookEdit n'est pas couvert ; ajoutez donc une règle `Edit` deny pour les chemins qu'aucun outil ne doit modifier. La vérification nécessite Claude Code v2.1.208 ou ultérieur pour les modifications, et v2.1.228 ou ultérieur pour les écritures.
376 388
377Claude Code vérifie les autorisations de fichier uniquement par rapport aux règles `Edit(path)` et `Read(path)`. Si vous écrivez une règle de chemin pour `Write`, `NotebookEdit`, `Glob` ou l'outil hérité `MultiEdit` à la place, Claude Code accepte la règle mais ne la consulte jamais, et [avertit au démarrage](/docs/fr/errors#is-not-matched-by-file-permission-checks), sauf pour une règle `Glob` passée dans `--allowedTools`. Utilisez `Edit(docs/**)` à la place de `Write(docs/**)`, `NotebookEdit(docs/**)` ou `MultiEdit(docs/**)`, et `Read(docs/**)` à la place de `Glob(docs/**)`. Claude Code n'avertit pas à propos d'une règle de nom d'outil sans chemin, telle qu'une règle de refus pour `Write` ; elle correspond à cette règle au niveau de l'outil partout. Nécessite Claude Code v2.1.210 ou ultérieur.389Claude Code vérifie les permissions de fichiers uniquement par rapport aux règles `Edit(path)` et `Read(path)`. Si vous écrivez plutôt une règle de chemin pour `Write`, `NotebookEdit`, `Glob` ou l'ancien outil `MultiEdit`, Claude Code accepte la règle mais ne la consulte jamais, et [affiche un avertissement au démarrage](/docs/fr/errors#is-not-matched-by-file-permission-checks), sauf pour une règle `Glob` passée dans `--allowedTools`. Utilisez `Edit(docs/**)` à la place de `Write(docs/**)`, `NotebookEdit(docs/**)` ou `MultiEdit(docs/**)`, et `Read(docs/**)` à la place de `Glob(docs/**)`. Claude Code n'affiche pas d'avertissement pour une règle portant sur un nom d'outil sans chemin, comme une règle deny pour `Write` ; il applique cette règle au niveau de l'outil partout. Nécessite Claude Code v2.1.210 ou ultérieur.
378 390
379<Warning>391<Warning>
380 Les règles de refus Read et Edit s'appliquent aux outils de fichier intégrés de Claude, aux commandes de fichier que Claude Code reconnaît dans Bash, telles que `cat`, `head`, `tail`, `sed` et `tee`, et aux cibles des [redirections](#redirections) Bash telles que `> file` et `< file`. Elles ne s'appliquent pas à une commande qui lit les fichiers sans les nommer, telle que `grep -r pattern .` exécutée à partir du répertoire qui contient le fichier, ou aux sous-processus arbitraires qui lisent ou écrivent des fichiers indirectement, comme un script Python ou Node qui ouvre des fichiers lui-même. Pour une application au niveau du système d'exploitation qui bloque tous les processus d'accéder à un chemin, [activez le sandbox](/docs/fr/sandboxing).392 Les règles Read et Edit deny s'appliquent aux outils de fichiers intégrés de Claude, aux commandes de fichiers que Claude Code reconnaît dans Bash, comme `cat`, `head`, `tail`, `sed` et `tee`, et aux cibles des [redirections](#redirections) Bash comme `> file` et `< file`. Elles ne s'appliquent pas à une commande qui lit des fichiers sans les nommer, comme `grep -r pattern .` exécuté depuis le répertoire qui contient le fichier, ni aux sous-processus arbitraires qui lisent ou écrivent des fichiers indirectement, comme un script Python ou Node qui ouvre lui-même des fichiers. Pour une application au niveau du système d'exploitation qui empêche tous les processus d'accéder à un chemin, [activez le sandbox](/docs/fr/sandboxing).
381</Warning>393</Warning>
382 394
383Les règles Read et Edit utilisent toutes deux la syntaxe de modèle [gitignore](https://git-scm.com/docs/gitignore) avec quatre types de modèles distincts ; pour les modèles de répertoire à segment unique, la profondeur de correspondance dépend également du type de règle, décrit plus loin dans cette section :395Les règles Read et Edit utilisent toutes deux la syntaxe de motifs [gitignore](https://git-scm.com/docs/gitignore) avec quatre types de motifs distincts ; pour les motifs de répertoire à un seul segment, la profondeur de correspondance dépend aussi du type de règle, comme décrit plus loin dans cette section :
384 396
385| Modèle | Signification | Exemple | Correspond |397| Motif | Signification | Exemple | Correspond à |
386| - | - | - | - |398| - | - | - | - |
387| `//path` | Chemin absolu à partir de la racine du système de fichiers | `Read(//Users/alice/secrets/**)` | `/Users/alice/secrets/**` |399| `//path` | Chemin absolu depuis la racine du système de fichiers | `Read(//Users/alice/secrets/**)` | `/Users/alice/secrets/**` |
388| `~/path` | Chemin à partir du répertoire home | `Read(~/Documents/*.pdf)` | `/Users/alice/Documents/*.pdf` |400| `~/path` | Chemin depuis le répertoire personnel | `Read(~/Documents/*.pdf)` | `/Users/alice/Documents/*.pdf` |
389| `/path` | Chemin relatif à la source des paramètres | `Edit(/src/**/*.ts)` | `<répertoire de travail principal>/src/**/*.ts` dans les paramètres du projet |401| `/path` | Chemin relatif à la source des paramètres | `Edit(/src/**/*.ts)` | `<primary working directory>/src/**/*.ts` dans les paramètres du projet |
390| `path` ou `./path` | Chemin relatif au répertoire courant | `Read(*.env)` | `<cwd>/*.env` |402| `path` ou `./path` | Chemin relatif au répertoire actuel | `Read(*.env)` | `<cwd>/*.env` |
391 403
392<Warning>404<Warning>
393 Un modèle comme `/Users/alice/file` n'est pas un chemin absolu. La barre oblique unique en début ancre à la source des paramètres, pas à la racine du système de fichiers. Utilisez `//Users/alice/file` pour les chemins absolus.405 Un motif comme `/Users/alice/file` n'est pas un chemin absolu. La barre oblique initiale unique ancre le motif à la source des paramètres, et non à la racine du système de fichiers. Utilisez `//Users/alice/file` pour les chemins absolus.
394</Warning>406</Warning>
395 407
396Un modèle `/path` s'ancre à un répertoire associé à la source des paramètres qui le définit, donc la même règle correspond à des emplacements différents selon l'endroit où vous la placez :408Un motif `/path` est ancré à un répertoire associé à la source des paramètres qui le définit. La même règle correspond donc à des emplacements différents selon l'endroit où vous la placez :
397 409
398| Règle définie dans | `/path` se résout à |410| Règle définie dans | `/path` est résolu en |
399| :- | :- |411| :- | :- |
400| Paramètres du projet à `.claude/settings.json` | `<répertoire de travail principal>/path` |412| Paramètres du projet dans `.claude/settings.json` | `<primary working directory>/path` |
401| Paramètres locaux à `.claude/settings.local.json` | `<répertoire de travail principal>/path` |413| Paramètres locaux dans `.claude/settings.local.json` | `<primary working directory>/path` |
402| Paramètres utilisateur à `~/.claude/settings.json` | `~/.claude/path` |414| Paramètres utilisateur dans `~/.claude/settings.json` | `~/.claude/path` |
403| Un fichier passé avec `--settings <file>` | `<répertoire du fichier>/path` |415| Un fichier passé avec `--settings <file>` | `<directory of file>/path` |
404| Drapeaux CLI ou règles de session | `<répertoire de travail principal>/path` |416| Flags CLI ou règles de session | `<primary working directory>/path` |
405 417
406Une règle que vous ajoutez via `/permissions` suit la ligne pour le fichier de paramètres dans lequel vous l'enregistrez.418Une règle que vous ajoutez via `/permissions` suit la ligne correspondant au fichier de paramètres dans lequel vous l'enregistrez.
407 419
408Les règles de paramètres locaux s'ancrent au [répertoire de travail principal](#working-directories) de la session, pas à la racine du référentiel où Claude Code [stocke le fichier](#permission-system) en v2.1.211 et ultérieur. Dans une session démarrée à la racine du référentiel, les deux répertoires sont les mêmes ; dans une session [worktree](/docs/fr/worktrees), une règle partagée telle que `Edit(/src/**)` correspond au répertoire `src/` propre de ce worktree.420À partir de la v2.1.211, les règles des paramètres locaux sont ancrées au [répertoire de travail principal](#working-directories) de la session, et non à la racine du dépôt où Claude Code [stocke le fichier](#permission-system). Dans une session démarrée à la racine du dépôt, les deux répertoires sont identiques ; dans une session de [worktree](/docs/fr/worktrees), une règle partagée comme `Edit(/src/**)` correspond au répertoire `src/` propre à ce worktree.
409 421
410Une règle de refus telle que `Read(/secrets/**)` dans les paramètres utilisateur bloque `~/.claude/secrets/**`, pas un répertoire `secrets` dans votre projet. Pour écrire une règle dans les paramètres utilisateur qui s'applique à l'intérieur de chaque projet, utilisez plutôt un chemin absolu `//` ou un chemin relatif à home `~/`.422Une règle deny comme `Read(/secrets/**)` dans les paramètres utilisateur bloque `~/.claude/secrets/**`, et non un répertoire `secrets` de votre projet. Pour écrire dans les paramètres utilisateur une règle qui s'applique dans chaque projet, utilisez plutôt un chemin absolu `//` ou un chemin relatif au répertoire personnel `~/`.
411 423
412Sur Windows, les chemins sont normalisés en forme POSIX avant la correspondance. `C:\Users\alice` devient `/c/Users/alice`, donc utilisez `//c/**/.env` pour correspondre aux fichiers `.env` n'importe où sur ce lecteur. Pour correspondre sur tous les lecteurs, utilisez `//**/.env`.424Sous Windows, les chemins sont normalisés au format POSIX avant la correspondance. `C:\Users\alice` devient `/c/Users/alice` ; utilisez donc `//c/**/.env` pour faire correspondre les fichiers `.env` n'importe où sur ce lecteur. Pour faire correspondre sur tous les lecteurs, utilisez `//**/.env`.
413 425
414Exemples :426Exemples :
415 427
416* `Edit(/docs/**)` : édite dans `<répertoire de travail principal>/docs/`, pas `/docs/` ou `<répertoire de travail principal>/.claude/docs/`428* `Edit(/docs/**)` : modifications dans `<primary working directory>/docs/`, et non dans `/docs/` ou `<primary working directory>/.claude/docs/`
417* `Read(~/.zshrc)` : lit le `.zshrc` de votre répertoire home429* `Read(~/.zshrc)` : lit le fichier `.zshrc` de votre répertoire personnel
418* `Edit(//tmp/scratch.txt)` : édite le chemin absolu `/tmp/scratch.txt`430* `Edit(//tmp/scratch.txt)` : modifie le chemin absolu `/tmp/scratch.txt`
419* `Read(src/**)` : en tant que règle d'autorisation, lit à partir de `<répertoire courant>/src/` uniquement ; en tant que règle de refus ou de demande, correspond à un répertoire `src` à n'importe quelle profondeur sous le répertoire courant431* `Read(src/**)` : en tant que règle allow, lit uniquement depuis `<current-directory>/src/` ; en tant que règle deny ou ask, correspond à un répertoire `src` à n'importe quelle profondeur sous le répertoire actuel
420 432
421Une règle ne correspond qu'aux fichiers sous son ancrage ; dans cette limite, la profondeur de correspondance dépend de la forme du modèle et, pour les modèles de répertoire à segment unique, du type de règle, décrit ci-dessous. Les noms de fichiers nus suivent la sémantique gitignore et correspondent à n'importe quelle profondeur, donc `Read(.env)` et `Read(**/.env)` sont équivalents :433Une règle ne correspond qu'aux fichiers situés sous son ancre ; dans cette limite, la profondeur de correspondance dépend de la forme du motif et, pour les motifs de répertoire à un seul segment, du type de règle, comme décrit ci-dessous. Les noms de fichiers nus suivent la sémantique gitignore et correspondent à n'importe quelle profondeur, de sorte que `Read(.env)` et `Read(**/.env)` sont équivalents :
422 434
423| Règle de refus | Bloque | Ne bloque pas |435| Règle deny | Bloque | Ne bloque pas |
424| - | - | - |436| - | - | - |
425| `Read(.env)` ou `Read(**/.env)` | tout `.env` au ou sous le répertoire courant | `.env` dans un répertoire parent ou un autre projet |437| `Read(.env)` ou `Read(**/.env)` | tout fichier `.env` dans ou sous le répertoire actuel | un `.env` dans un répertoire parent ou dans un autre projet |
426| `Read(//**/.env)` | tout `.env` n'importe où sur le système de fichiers | rien ; la règle est ancrée à la racine du système de fichiers |438| `Read(//**/.env)` | tout fichier `.env` n'importe où sur le système de fichiers | rien ; la règle est ancrée à la racine du système de fichiers |
427 439
428Un modèle relatif avec un segment de répertoire unique, tel que `src/**`, correspond à des profondeurs différentes selon le type de règle :440Un motif relatif comportant un seul segment de répertoire, comme `src/**`, correspond à des profondeurs différentes selon le type de règle :
429 441
430* **Règles d'autorisation** : `Edit(src/**)` correspond uniquement à `<cwd>/src` et aux fichiers sous celui-ci. Pour autoriser un nom de répertoire à n'importe quelle profondeur, écrivez `Edit(**/src/**)`.442* **Règles allow** : `Edit(src/**)` correspond uniquement à `<cwd>/src` et aux fichiers qu'il contient. Pour autoriser un nom de répertoire à n'importe quelle profondeur, écrivez `Edit(**/src/**)`.
431* **Règles de refus et de demande** : `Read(secrets/**)` correspond à un répertoire nommé `secrets` à n'importe quelle profondeur sous le répertoire courant, donc la règle s'applique également aux copies imbriquées.443* **Règles deny et ask** : `Read(secrets/**)` correspond à un répertoire nommé `secrets` à n'importe quelle profondeur sous le répertoire actuel, de sorte que la règle s'applique aussi aux copies imbriquées.
432 444
433Chaque autre forme de modèle correspond à la même profondeur dans chaque type de règle : `Edit(/src/**)` et `Edit(src/components/**)` correspondent uniquement à leur emplacement ancré, tandis que `Edit(**/src/**)` correspond à n'importe quelle profondeur.445Toutes les autres formes de motifs correspondent à la même profondeur quel que soit le type de règle : `Edit(/src/**)` et `Edit(src/components/**)` ne correspondent qu'à leur emplacement ancré, tandis que `Edit(**/src/**)` correspond à n'importe quelle profondeur.
434 446
435L'exemple suivant montre chaque forme de modèle par rapport à un projet avec un répertoire `src/` de niveau supérieur et une copie imbriquée sous `vendor/` :447L'exemple suivant montre chaque forme de motif appliquée à un projet comportant un répertoire `src/` de premier niveau et une copie imbriquée sous `vendor/` :
436 448
437```text theme={null}449```text theme={null}
438<répertoire courant>/450<current-directory>/
439├── src/451├── src/
440│ └── app.ts452│ └── app.ts
441└── vendor/453└── vendor/
446 458
447| Règle | Correspond à `src/app.ts` | Correspond à `vendor/pkg/src/lib.js` |459| Règle | Correspond à `src/app.ts` | Correspond à `vendor/pkg/src/lib.js` |
448| :- | :- | :- |460| :- | :- | :- |
449| `Edit(src/**)` en tant que règle d'autorisation | Oui | Non |461| `Edit(src/**)` en tant que règle allow | Oui | Non |
450| `Edit(src/**)` en tant que règle de refus ou de demande | Oui | Oui |462| `Edit(src/**)` en tant que règle deny ou ask | Oui | Oui |
451| `Edit(/src/**)` dans n'importe quel type de règle | Oui | Non |463| `Edit(/src/**)` dans tout type de règle | Oui | Non |
452| `Edit(**/src/**)` dans n'importe quel type de règle | Oui | Oui |464| `Edit(**/src/**)` dans tout type de règle | Oui | Oui |
453 465
454<Note>466<Note>
455 Dans les modèles gitignore, `*` correspond dans un seul segment de chemin et peut apparaître à n'importe quelle position du modèle, tandis que `**` correspond sur les répertoires.467 Dans les motifs gitignore, `*` correspond à l'intérieur d'un seul segment de chemin et peut apparaître à n'importe quelle position du motif, tandis que `**` correspond à travers les répertoires.
456</Note>468</Note>
457 469
458Lorsque vous approuvez un chemin de fichier avec « Oui, ne pas demander à nouveau », Claude Code échappe les caractères de modèle gitignore dans ce chemin, tels que `[`, `]` et `*`, afin que la règle générée ne corresponde qu'au chemin littéral que vous avez approuvé. Les règles que vous écrivez vous-même ne sont pas échappées. Avant la v2.1.202, Claude Code enregistrait le chemin non échappé, donc une règle générée pour un répertoire nommé `[2024-06] Reports` pouvait échouer à correspondre à son propre chemin ou correspondre à des répertoires frères non intentionnels.470Lorsque vous approuvez un chemin de fichier avec « Yes, and don't ask again », Claude Code échappe les caractères de motif gitignore présents dans ce chemin, comme `[`, `]` et `*`, de sorte que la règle générée ne correspond qu'au chemin littéral que vous avez approuvé. Les règles que vous écrivez vous-même ne sont pas échappées. Avant la v2.1.202, Claude Code enregistrait le chemin sans échappement, si bien qu'une règle générée pour un répertoire nommé `[2024-06] Reports` pouvait ne pas correspondre à son propre chemin ou correspondre à des répertoires frères non souhaités.
459 471
460Vous n'avez pas besoin d'échapper les parenthèses dans un chemin, donc `Edit(./Finance (2024)/**)` correspond au dossier `Finance (2024)` tel qu'épelé.472Vous n'avez pas besoin d'échapper les parenthèses dans un chemin : `Edit(./Finance (2024)/**)` correspond au dossier `Finance (2024)` tel qu'il est écrit.
461 473
462Une règle de refus ou de demande dont le chemin n'est pas utilisable comme modèle gitignore protège toujours ce chemin exact. Une règle d'autorisation avec un modèle inutilisable n'approuve rien.474Une règle deny ou ask dont le chemin n'est pas utilisable comme motif gitignore protège tout de même ce chemin exact. Une règle allow avec un motif inutilisable n'approuve rien.
463 475
464Une règle de refus ou de demande dont le chemin commence par `!` est une négation gitignore. Elle découpe les chemins qu'elle correspond hors des règles `path` ou `./path` énumérées avant elle. Dans la liste `deny` d'un fichier de paramètres, `Read(*.env)` suivi de `Read(!sample.env)` bloque chaque fichier dont le nom se termine par `.env` à n'importe quelle profondeur, sauf les fichiers nommés `sample.env`. Une règle `!` énumérée en premier ne découpe rien.476Un motif deny ou ask qui commence par `!` est une négation gitignore. Il exclut les chemins auxquels il correspond des règles `path` ou `./path` listées avant lui. Dans la liste `deny` d'un même fichier de paramètres, `Read(*.env)` suivi de `Read(!sample.env)` bloque tout fichier dont le nom se termine par `.env` à n'importe quelle profondeur, sauf les fichiers nommés `sample.env`. Une règle `!` listée en premier n'exclut rien.
465 477
466La découpe ne s'étend qu'aux règles de la même source. Un `Read(!.env)` dans les paramètres du projet ou dans `--disallowedTools` n'annule pas un refus `Read(./.env)` des paramètres gérés ou de tout autre fichier de paramètres.478L'exclusion ne concerne que les règles provenant de la même source. Un `Read(!.env)` dans les paramètres du projet ou dans `--disallowedTools` n'annule pas une règle deny `Read(./.env)` provenant des paramètres gérés ou de tout autre fichier de paramètres.
467 479
468Deux limites réduisent ce qu'un modèle `!` peut découper :480Deux limites restreignent ce qu'un motif `!` peut exclure :
469 481
470* Claude Code lit un modèle `!` relatif au répertoire courant même lorsque `/`, `~/` ou `//` suit le `!`, donc le modèle ne peut pas atteindre une règle ancrée avec l'un de ces préfixes. `Read(!~/notes/public/**)` ne découpe rien hors de `Read(~/notes/**)`.482* Claude Code interprète un motif `!` par rapport au répertoire actuel même lorsque `/`, `~/` ou `//` suit le `!`, de sorte que le motif ne peut pas atteindre une règle ancrée avec l'un de ces préfixes. `Read(!~/notes/public/**)` n'exclut rien de `Read(~/notes/**)`.
471* Une découpe ne peut pas rouvrir un fichier à l'intérieur d'un répertoire qu'une règle bloque dans son ensemble. Avec `Read(secrets/**)` et `Read(!secrets/public/**)`, Claude Code bloque toujours `secrets/public` avec le reste de `secrets`.483* Une exclusion ne peut pas rouvrir un fichier situé dans un répertoire qu'une règle bloque dans son ensemble. Avec `Read(secrets/**)` et `Read(!secrets/public/**)`, Claude Code bloque toujours `secrets/public` ainsi que le reste de `secrets`.
472 484
473<h4 id="symlinks">485<h4 id="symlinks">
474 Liens symboliques486 Liens symboliques
475</h4>487</h4>
476 488
477Lorsqu'un chemin de fichier que Claude demande passe par un lien symbolique, la vérification d'autorisation couvre deux chemins : celui que Claude a demandé et le fichier vers lequel il se résout. Cela s'applique aux liens symboliques sur macOS, Linux et Windows, et aux jonctions de répertoires sur Windows.489Lorsqu'un chemin de fichier demandé par Claude passe par un lien symbolique, la vérification des permissions porte sur deux chemins : celui que Claude a demandé et le fichier vers lequel il est résolu. Cela s'applique aux liens symboliques sous macOS, Linux et Windows, ainsi qu'aux jonctions de répertoires sous Windows.
478 490
479<h5 id="how-rules-match-a-symlinked-path">491<h5 id="how-rules-match-a-symlinked-path">
480 Comment les règles correspondent à un chemin lié symboliquement492 Comment les règles correspondent à un chemin passant par un lien symbolique
481</h5>493</h5>
482 494
483Les règles d'autorisation et de refus traitent le chemin demandé et le fichier vers lequel il se résout différemment :495Les règles allow et deny traitent différemment le chemin demandé et le fichier vers lequel il est résolu :
484 496
485* **Règles d'autorisation** : s'appliquent uniquement lorsque le chemin demandé et le fichier vers lequel il se résout correspondent tous les deux. Une lecture via un lien symbolique à l'intérieur d'un répertoire autorisé qui pointe vers l'extérieur ne correspond pas à la règle.497* **Règles allow** : ne s'appliquent que lorsque le chemin demandé et le fichier vers lequel il est résolu correspondent tous les deux. Une lecture via un lien symbolique situé dans un répertoire autorisé et pointant en dehors de celui-ci ne correspond pas à la règle.
486* **Règles de refus** : s'appliquent lorsque le chemin demandé ou le fichier vers lequel il se résout correspond. Un lien symbolique qui pointe vers un fichier refusé est lui-même refusé. Par exemple, avec `Read(./project/**)` autorisé et `Read(~/.ssh/**)` refusé, un lien symbolique à `./project/key` pointant vers `~/.ssh/id_rsa` est bloqué : la cible échoue à la règle d'autorisation et correspond à la règle de refus.498* **Règles deny** : s'appliquent lorsque le chemin demandé ou le fichier vers lequel il est résolu correspond. Un lien symbolique qui pointe vers un fichier refusé est lui-même refusé. Par exemple, avec `Read(./project/**)` autorisé et `Read(~/.ssh/**)` refusé, un lien symbolique situé à `./project/key` et pointant vers `~/.ssh/id_rsa` est bloqué : la cible ne satisfait pas la règle allow et correspond à la règle deny.
487 499
488Sur macOS et Linux, une règle de refus ou de demande écrite via un répertoire lié symboliquement avec un modèle `//`, `~/` ou `/` s'applique également à l'emplacement réel du répertoire. Par exemple, sur macOS, où `/etc` se résout à `/private/etc`, `Read(//etc/**)` bloque également `/private/etc/hosts`. Avant la v2.1.268, une règle de refus ou de demande écrite via un répertoire lié symboliquement ne s'appliquait pas à un chemin donné par son emplacement réel.500Sous macOS et Linux, une règle deny ou ask écrite via un répertoire qui est un lien symbolique avec un motif `//`, `~/` ou `/` s'applique également à l'emplacement réel du répertoire. Par exemple, sous macOS, où `/etc` est résolu en `/private/etc`, `Read(//etc/**)` bloque aussi `/private/etc/hosts`. Avant la v2.1.268, une règle deny ou ask écrite via un répertoire qui est un lien symbolique ne s'appliquait pas à un chemin indiqué par son emplacement réel.
489 501
490Grep et Glob recherchent le répertoire auquel l'argument `path` se résout. Claude Code applique les règles de refus `Read` à ce répertoire.502Grep et Glob effectuent leur recherche dans le répertoire vers lequel l'argument `path` est résolu. Claude Code applique les règles `Read` deny à ce répertoire.
491 503
492<h5 id="writes-through-a-symlink">504<h5 id="writes-through-a-symlink">
493 Écritures via un lien symbolique505 Écritures via un lien symbolique
494</h5>506</h5>
495 507
496Si le chemin que Claude demande d'éditer ou d'écrire est lui-même un lien symbolique, les outils Edit et Write [refusent l'écriture et dirigent Claude vers la cible du lien](/docs/fr/errors#refusing-after-a-symlink-changed).508Si le chemin que Claude demande de modifier ou d'écrire est lui-même un lien symbolique, les outils Edit et Write [refusent l'écriture et redirigent Claude vers la cible du lien](/docs/fr/errors#refusing-after-a-symlink-changed).
497 509
498Une écriture peut toujours passer par un lien symbolique lorsqu'un répertoire sur le chemin du fichier est un lien symbolique, ou lorsqu'une commande Bash ou PowerShell fait l'écriture. Pour ces écritures, ce qui se passe dépend de l'endroit où le fichier vers lequel l'écriture se résout se situe par rapport à vos [répertoires de travail](#working-directories) et aux [chemins protégés](/docs/fr/permission-modes#protected-paths) :510Une écriture peut tout de même passer par un lien symbolique lorsqu'un répertoire sur le chemin du fichier est un lien symbolique, ou lorsqu'une commande Bash ou PowerShell effectue l'écriture. Pour ces écritures, le comportement dépend de l'emplacement du fichier vers lequel l'écriture est résolue par rapport à vos [répertoires de travail](#working-directories) et aux [chemins protégés](/docs/fr/permission-modes#protected-paths) :
499 511
500* **Se résout en dehors des répertoires de travail** : lorsque le chemin demandé est à l'intérieur de vos répertoires de travail et que le fichier vers lequel il se résout ne l'est pas, l'écriture n'est pas approuvée automatiquement en [mode `acceptEdits`](/docs/fr/permission-modes#auto-approve-file-edits-with-acceptedits-mode). En [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode), sauf si une règle d'autorisation approuve l'écriture, vous êtes invité à la place du classificateur qui décide. L'invite nomme le chemin vers lequel l'écriture se résout.512* **Résolution en dehors des répertoires de travail** : lorsque le chemin demandé se trouve dans vos répertoires de travail et que le fichier vers lequel il est résolu n'y est pas, l'écriture n'est pas approuvée automatiquement en [mode `acceptEdits`](/docs/fr/permission-modes#auto-approve-file-edits-with-acceptedits-mode). En [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode), sauf si une règle allow approuve l'écriture, une demande vous est présentée au lieu de laisser le classifieur décider. La demande indique le chemin vers lequel l'écriture est résolue.
501* **Se résout à un chemin protégé que le chemin demandé ne nomme pas** : le [tableau des chemins protégés](/docs/fr/permission-modes#protected-paths) donne le résultat pour chaque mode d'autorisation, sauf que là où le tableau route l'écriture vers le classificateur, cette écriture vous invite à la place.513* **Résolution vers un chemin protégé que le chemin demandé ne désigne pas** : le [tableau des chemins protégés](/docs/fr/permission-modes#protected-paths) indique le résultat pour chaque mode de permission, sauf que là où le tableau confie l'écriture au classifieur, cette écriture vous est soumise sous forme de demande.
502 514
503<h5 id="paths-that-can’t-be-resolved-or-that-change">515<h5 id="paths-that-can’t-be-resolved-or-that-change">
504 Chemins qui ne peuvent pas être résolus ou qui changent516 Chemins impossibles à résoudre ou qui changent
505</h5>517</h5>
506 518
507Lorsque Claude Code ne peut pas déterminer où un chemin mène sur le disque, par exemple parce que les liens symboliques sur celui-ci forment une boucle, les outils Read, Edit et Write [refusent l'opération](/docs/fr/errors#refusing-after-a-symlink-changed).519Lorsque Claude Code ne peut pas déterminer où un chemin mène sur le disque, par exemple parce que des liens symboliques sur ce chemin forment une boucle, les outils Read, Edit et Write [refusent l'opération](/docs/fr/errors#refusing-after-a-symlink-changed).
520
521Lorsqu'un outil ouvre ensuite le fichier approuvé, il [vérifie que le chemin est toujours résolu vers l'emplacement approuvé par la vérification des permissions](/docs/fr/errors#refusing-after-a-symlink-changed).
522
523<h4 id="network-paths">
524 Chemins réseau
525</h4>
526
527Lorsque les outils de lecture de fichiers de Claude, comme Read, Grep et Glob, lisent depuis un chemin réseau, la lecture fait l'objet de sa propre vérification de permission. Un chemin réseau est un chemin qui peut atteindre un autre ordinateur : sous Windows, un chemin UNC comme `\\server\share\file`, et sous macOS et Linux, un chemin d'automontage `/net` comme `/net/fileserver/notes.txt`. La résolution d'un tel chemin peut contacter l'hôte qu'il désigne et, sous Windows, ce contact peut envoyer vos identifiants à l'hôte. Les commandes shell ont leur propre vérification : en mode Manual, une commande Bash ou PowerShell en lecture seule dont les arguments incluent un chemin UNC [déclenche toujours une demande sous Windows](#read-only-commands).
528
529À partir de Claude Code v2.1.292, aucun des éléments suivants ne supprime la demande :
530
531* **Règles allow** : une règle ne pré-approuve pas la lecture, y compris une règle pour l'outil entier, comme `Read`
532* **Hooks PreToolUse** : un [hook](#extend-permissions-with-hooks) qui renvoie `"allow"` ne contourne pas la demande
533* **Mode auto** : la demande vous est présentée, et le [classifieur](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode) ne décide pas de la lecture
534
535En mode `dontAsk`, Claude Code refuse la lecture au lieu de vous la demander. En mode `bypassPermissions`, ainsi que dans les sessions de terminal interactives en mode plan où [bypass permissions](/docs/fr/permission-modes#skip-all-checks-with-bypasspermissions-mode) est disponible, la lecture s'exécute sans cette demande.
536
537Pour lire des fichiers sur un partage réseau sans cette demande, donnez d'abord au partage un chemin local :
508 538
509Lorsqu'un outil ouvre ensuite le fichier approuvé, il [confirme que le chemin se résout toujours à l'emplacement que la vérification d'autorisation a approuvé](/docs/fr/errors#refusing-after-a-symlink-changed).539* **Windows** : mappez le partage à une lettre de lecteur et passez ce lecteur avec `--add-dir` lorsque vous lancez Claude Code, comme décrit dans [Répertoires de travail](#working-directories)
540* **macOS et Linux** : montez le partage sur un chemin local, comme un répertoire sous `/mnt` ou `/Volumes`, et lisez les fichiers depuis cet emplacement, comme décrit dans [Working directory is a network path](/docs/fr/errors#working-directory-is-a-network-path)
510 541
511<h3 id="webfetch">542<h3 id="webfetch">
512 WebFetch543 WebFetch
513</h3>544</h3>
514 545
515Les règles WebFetch utilisent un préfixe `domain:` et correspondent au nom d'hôte de l'URL demandée. La correspondance est insensible à la casse, prend en charge les caractères génériques `*` et supprime un point final des deux côtés de la règle et du nom d'hôte afin que `example.com.` et `example.com` soient traités de la même manière.546Les règles WebFetch utilisent un préfixe `domain:` et sont comparées au nom d'hôte de l'URL demandée. La correspondance ne tient pas compte de la casse, prend en charge les caractères génériques `*` et supprime un `.` final à la fois dans la règle et dans le nom d'hôte, de sorte que `example.com.` et `example.com` sont traités de la même façon.
516 547
517* `WebFetch(domain:example.com)` correspond aux demandes vers `example.com`548* `WebFetch(domain:example.com)` correspond uniquement aux requêtes vers `example.com`. Pour couvrir aussi les sous-domaines comme `api.example.com`, ajoutez une règle `WebFetch(domain:*.example.com)`
518* `WebFetch(domain:*.example.com)` correspond à tout sous-domaine à n'importe quelle profondeur, comme `api.example.com` ou `a.b.example.com`, mais pas à `example.com` lui-même549* `WebFetch(domain:*.example.com)` correspond à tout sous-domaine, quelle que soit sa profondeur, comme `api.example.com` ou `a.b.example.com`, mais pas à `example.com` lui-même
519* `WebFetch(domain:*)` correspond à chaque domaine. Ce n'est pas la même chose qu'une règle `WebFetch` nu ; voir [Autoriser ou refuser chaque fetch](#allow-or-deny-every-fetch)550* `WebFetch(domain:*)` correspond à tous les domaines. Ce n'est pas l'équivalent d'une règle `WebFetch` nue ; consultez [Autoriser ou refuser toutes les récupérations](#allow-or-deny-every-fetch)
520 551
521À n'importe quelle position autre qu'un `*.` initial ou un `*` nu, le caractère générique correspond uniquement au texte entre deux points. `WebFetch(domain:example.*)` correspond à `example.org`, où `*` devient `org`, mais pas à `example.evil.com`, où `*` devrait devenir `evil.com` et traverser un point. Cela empêche un caractère générique de fin de correspondre à des domaines qu'un attaquant pourrait enregistrer.552À toute position autre qu'un `*.` initial ou un `*` seul, le caractère générique ne correspond qu'au texte situé entre deux points. `WebFetch(domain:example.*)` correspond à `example.org`, où `*` devient `org`, mais pas à `example.evil.com`, où `*` devrait devenir `evil.com` et franchir un point. Cela empêche un caractère générique final de correspondre à des domaines qu'un attaquant pourrait enregistrer.
522 553
523Les caractères génériques dans les règles `WebFetch` nécessitent Claude Code v2.1.172 ou ultérieur pour correspondre aux fetches.554Les caractères génériques dans les règles `WebFetch` nécessitent Claude Code v2.1.172 ou ultérieur pour correspondre aux récupérations.
524 555
525<h4 id="allow-or-deny-every-fetch">556<h4 id="allow-or-deny-every-fetch">
526 Autoriser ou refuser chaque fetch557 Autoriser ou refuser toutes les récupérations
527</h4>558</h4>
528 559
529Une règle `WebFetch` nu est le nom de l'outil sans partie `domain:`, telle que `"deny": ["WebFetch"]`. À la fois elle et `WebFetch(domain:*)` couvrent chaque URL, mais Claude Code les applique différemment, et seule la forme `domain:` ajoute également son domaine à la [liste de domaines autorisés ou refusés](/docs/fr/sandboxing#network-isolation) du sandbox. Cette section énumère les formes de caractères génériques que le sandbox honore et la version qui a ajouté le `*` nu.560Une règle `WebFetch` nue est le nom de l'outil sans partie `domain:`, comme `"deny": ["WebFetch"]`. Elle et `WebFetch(domain:*)` couvrent toutes les URL, mais Claude Code les applique différemment, et seule la forme `domain:` ajoute aussi son domaine à la [liste des domaines autorisés ou refusés](/docs/fr/sandboxing#network-isolation) du sandbox. Cette section liste les formes de caractères génériques prises en compte par le sandbox et la version qui a ajouté le `*` seul.
530 561
531Chaque ligne montre ce qu'une règle fait dans la liste `allow` et dans la liste `deny` :562Chaque ligne indique l'effet d'une règle dans la liste `allow` et dans la liste `deny` :
532 563
533| Règle | Dans `allow` | Dans `deny` |564| Règle | Dans `allow` | Dans `deny` |
534| :- | :- | :- |565| :- | :- | :- |
535| `WebFetch` | Claude fetch sans vous inviter. Ne change pas quels hôtes les commandes en sandbox peuvent atteindre. | Claude Code supprime l'outil `WebFetch`, donc Claude ne peut pas fetch du tout. Ne change pas quels hôtes les commandes en sandbox peuvent atteindre. |566| `WebFetch` | Claude effectue les récupérations sans vous demander de permission. Ne modifie pas les hôtes que les commandes en sandbox peuvent atteindre. | Claude Code retire l'outil `WebFetch`, de sorte que Claude ne peut rien récupérer. Ne modifie pas les hôtes que les commandes en sandbox peuvent atteindre. |
536| `WebFetch(domain:*)` | Claude fetch sans vous inviter, et les commandes en sandbox peuvent atteindre n'importe quel hôte. | Claude Code garde l'outil et refuse chaque fetch, et les commandes en sandbox ne peuvent atteindre aucun hôte. |567| `WebFetch(domain:*)` | Claude effectue les récupérations sans vous demander de permission, et les commandes en sandbox peuvent atteindre n'importe quel hôte. | Claude Code conserve l'outil et refuse chaque récupération, et les commandes en sandbox ne peuvent atteindre aucun hôte. |
537 568
538Les deux formes diffèrent également sur les lectures des [artifacts](/docs/fr/artifacts), les pages que l'outil Artifact publie sur claude.ai. Une règle de refus ou de demande `WebFetch` nu ne s'applique pas à ces lectures. Une règle `domain:` couvrant `claude.ai` ou l'hôte de contenu `*.claudeusercontent.com`, telle que `WebFetch(domain:claude.ai)` ou `WebFetch(domain:*)`, refuse chaque lecture ou demande avant celle-ci. Une règle [`Artifact`](/docs/fr/artifacts#disable-artifacts) fait la même chose.569Les deux formes diffèrent également pour les lectures d'[artefacts](/docs/fr/artifacts), les pages que l'outil Artifact publie sur claude.ai. Une règle `WebFetch` deny ou ask nue ne s'applique pas à ces lectures. Une règle `domain:` couvrant `claude.ai` ou l'hôte de contenu `*.claudeusercontent.com`, comme `WebFetch(domain:claude.ai)` ou `WebFetch(domain:*)`, refuse chaque lecture ou déclenche une demande avant celle-ci. Une [règle `Artifact`](/docs/fr/artifacts#disable-artifacts) a le même effet.
539 570
540Lorsqu'une règle bloque une lecture, le refus nomme la règle. Avant la v2.1.268, une règle de refus `WebFetch` nu bloquait chaque lecture d'artifact, et une règle de demande nu demandait avant chacune.571Lorsqu'une règle bloque une lecture, le refus indique le nom de la règle. Avant la v2.1.268, une règle `WebFetch` deny nue bloquait toutes les lectures d'artefacts, et une règle ask nue déclenchait une demande avant chacune d'elles.
541 572
542Pour laisser Claude fetch librement tout en gardant la liste d'autorisation du sandbox telle qu'elle est, utilisez la forme nu. Ce `settings.json` fait cela :573Pour laisser Claude effectuer des récupérations librement tout en conservant la liste d'autorisation du sandbox telle quelle, utilisez la forme nue. Ce `settings.json` fait exactement cela :
543 574
544```json theme={null}575```json theme={null}
545{576{
549}580}
550```581```
551 582
552Lorsque vous demandez à Claude de fetch une page, il fetch sans invite. Lorsque vous lui demandez d'exécuter un `curl` [en sandbox](/docs/fr/sandboxing) contre un hôte en dehors de la liste d'autorisation du sandbox, Claude Code vous invite toujours pour cet hôte, car la règle nu n'a pas ajouté l'hôte à la liste d'autorisation.583Lorsque vous demandez à Claude de récupérer une page, il le fait sans demande de permission. Lorsque vous lui demandez d'exécuter un `curl` [en sandbox](/docs/fr/sandboxing) vers un hôte qui ne figure pas dans la liste d'autorisation du sandbox, Claude Code vous demande toujours une permission pour cet hôte, car la règle nue n'a pas ajouté l'hôte à la liste d'autorisation.
553 584
554En [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode), Claude nomme plutôt l'hôte dans les [domaines autorisés par commande](/docs/fr/sandboxing#per-command-allowed-domains-in-auto-mode) de la commande pour que le classificateur examine.585En [mode auto](/docs/fr/permission-modes#eliminate-prompts-with-auto-mode), Claude indique plutôt l'hôte dans les [domaines autorisés par commande](/docs/fr/sandboxing#per-command-allowed-domains-in-auto-mode) pour que le classifieur l'examine.
555 586
556<h3 id="mcp">587<h3 id="mcp">
557 MCP588 MCP
558</h3>589</h3>
559 590
560Les règles MCP utilisent le nom du serveur tel que configuré dans Claude Code, optionnellement suivi du nom d'un outil de ce serveur.591Les règles MCP utilisent le nom du serveur tel que configuré dans Claude Code, éventuellement suivi du nom d'un outil de ce serveur.
561 592
562* `mcp__puppeteer` correspond à tout outil fourni par le serveur `puppeteer`593* `mcp__puppeteer` correspond à tout outil fourni par le serveur `puppeteer`
563* `mcp__puppeteer__*` utilise la syntaxe de caractère générique et correspond également à tous les outils du serveur `puppeteer`594* `mcp__puppeteer__*` utilise la syntaxe des caractères génériques et correspond également à tous les outils du serveur `puppeteer`
564* `mcp__puppeteer__puppeteer_navigate` correspond à l'outil `puppeteer_navigate` fourni par le serveur `puppeteer`595* `mcp__puppeteer__puppeteer_navigate` correspond à l'outil `puppeteer_navigate` fourni par le serveur `puppeteer`
565 596
566Si votre organisation a défini un outil de connecteur [claude.ai](/docs/fr/mcp#organization-controls-on-connector-tools) sur `ask` et que ce paramètre atteint Claude Code dans votre session, les règles d'autorisation pour cet outil ne prennent pas effet : Claude Code demande à chaque appel, même en modes `auto` et `bypassPermissions`. En mode `dontAsk`, qui ne demande jamais, Claude Code refuse l'appel à la place. Les outils de connecteur que Claude Code récupère lui-même apparaissent comme `mcp__claude_ai_<server>__<tool>`.597Si votre organisation a défini un outil de [connecteur claude.ai](/docs/fr/mcp#organization-controls-on-connector-tools) sur `ask` et que ce paramètre parvient à Claude Code dans votre session, les règles allow pour cet outil ne prennent pas effet : Claude Code demande une permission à chaque appel, même dans les modes `auto` et `bypassPermissions`. En mode `dontAsk`, qui ne demande jamais de permission, Claude Code refuse plutôt l'appel. Les outils des connecteurs que Claude Code récupère lui-même apparaissent sous la forme `mcp__claude_ai_<server>__<tool>`.
567 598
568Dans une session [Cowork](https://claude.com/docs/cowork/overview) dans l'application Claude Desktop, Claude exécute les commandes shell via l'outil `mcp__workspace__bash` de Cowork plutôt que l'outil `Bash` intégré, et Cowork fournit également `mcp__workspace__web_fetch` pour les web fetches. Claude Code applique également les règles de refus qui nomment l'outil entier `Bash` ou `WebFetch` à ces outils Cowork, donc une règle de refus `Bash` gérée empêche Claude d'exécuter des commandes shell dans Cowork. Lorsque Claude Code bloque un tel appel, le message nomme l'outil Cowork : `Permission to use mcp__workspace__bash has been denied.` Les règles d'autorisation ne se reportent pas : Claude Code n'applique jamais une règle d'autorisation `Bash` à `mcp__workspace__bash`.599Dans une session [Cowork](https://claude.com/docs/cowork/overview) de l'application Claude Desktop, Claude exécute les commandes shell via l'outil `mcp__workspace__bash` de Cowork plutôt que via l'outil intégré `Bash`, et Cowork fournit de même `mcp__workspace__web_fetch` pour les récupérations web. Claude Code applique aussi à ces outils Cowork les règles deny qui désignent l'outil `Bash` ou `WebFetch` dans son ensemble, de sorte qu'une règle deny `Bash` gérée empêche Claude d'exécuter des commandes shell dans Cowork. Lorsque Claude Code bloque un tel appel, le message indique l'outil Cowork : `Permission to use mcp__workspace__bash has been denied.` Les règles allow ne sont pas reportées : Claude Code n'applique jamais une règle allow `Bash` à `mcp__workspace__bash`.
569 600
570<h3 id="agent-subagents">601<h3 id="agent-subagents">
571 Agent (subagents)602 Agent (sous-agents)
572</h3>603</h3>
573 604
574Utilisez les règles `Agent(AgentName)` pour contrôler quels [subagents](/docs/fr/sub-agents) Claude peut utiliser :605Utilisez des règles `Agent(AgentName)` pour contrôler les [sous-agents](/docs/fr/sub-agents) que Claude peut utiliser :
575 606
576* `Agent(Explore)` correspond au subagent Explore607* `Agent(Explore)` correspond au sous-agent Explore
577* `Agent(Plan)` correspond au subagent Plan608* `Agent(Plan)` correspond au sous-agent Plan
578* `Agent(my-custom-agent)` correspond à un subagent personnalisé nommé `my-custom-agent`609* `Agent(my-custom-agent)` correspond à un sous-agent personnalisé nommé `my-custom-agent`
579 610
580Ajoutez ces règles au tableau `deny` dans vos paramètres ou utilisez l'indicateur CLI `--disallowedTools` pour désactiver des agents spécifiques. Pour désactiver l'agent Explore :611Ajoutez ces règles au tableau `deny` de vos paramètres ou utilisez le flag CLI `--disallowedTools` pour désactiver des agents spécifiques. Pour désactiver l'agent Explore :
581 612
582```json theme={null}613```json theme={null}
583{614{
591 Cd622 Cd
592</h3>623</h3>
593 624
594Les règles `Cd` contrôlent les répertoires vers lesquels la [commande `/cd`](/docs/fr/commands) peut déplacer la session. `Cd` n'est pas un outil invocable par le modèle : Claude ne peut pas l'appeler, et les règles s'appliquent uniquement lorsque vous exécutez `/cd` vous-même.625Les règles `Cd` contrôlent les répertoires vers lesquels la [commande `/cd`](/docs/fr/commands) peut déplacer la session. `Cd` n'est pas un outil que le modèle peut invoquer : Claude ne peut pas l'appeler, et les règles ne s'appliquent que lorsque vous exécutez `/cd` vous-même.
595 626
596Une règle de refus `Cd` nu désactive `/cd` entièrement. Une règle de refus `Cd(<path-pattern>)` bloque les cibles correspondantes. Les règles de refus vérifient chaque orthographe de la cible, y compris chaque saut de lien symbolique qu'elle résout, donc une règle écrite pour un chemin bloque également les cibles qui s'y résolvent.627Une règle `Cd` deny nue désactive entièrement `/cd`. Une règle deny `Cd(<path-pattern>)` bloque les cibles correspondantes. Les règles deny vérifient toutes les écritures possibles de la cible, y compris chaque étape de lien symbolique par laquelle elle est résolue, de sorte qu'une règle écrite pour un chemin bloque aussi les cibles qui sont résolues vers celui-ci.
597 628
598L'ajout de toute règle d'autorisation `Cd` bascule `/cd` en mode liste blanche : le répertoire cible résolu doit correspondre à l'une de vos règles d'autorisation, ou `/cd` refuse. Sans règles `Cd` configurées, `/cd` conserve son comportement par défaut et vous invite à faire confiance à un répertoire inconnu.629L'ajout de toute règle `Cd` allow fait passer `/cd` en mode liste d'autorisation : le répertoire cible résolu doit correspondre à l'une de vos règles allow, sinon `/cd` refuse. Sans règle `Cd` configurée, `/cd` conserve son comportement par défaut et vous demande de faire confiance à un répertoire inconnu.
599 630
600Les modèles de chemin partagent les ancrages `//`, `~/` et `/` des [règles Read et Edit](#read-and-edit), mais la correspondance est ancrée au chemin du répertoire entier plutôt qu'au style gitignore. `*` correspond à exactement un segment de chemin et `**` correspond sur les segments. Un `/**` de fin correspond également à sa racine nommée.631Les motifs de chemin partagent les ancres `//`, `~/` et `/` des [règles Read et Edit](#read-and-edit), mais la correspondance porte sur le chemin complet du répertoire plutôt que de suivre le style gitignore. `*` correspond exactement à un segment de chemin et `**` correspond à travers plusieurs segments. Un `/**` final correspond aussi à la racine qu'il nomme.
601 632
602| Règle | Correspond | Ne correspond pas |633| Règle | Correspond à | Ne correspond pas à |
603| - | - | - |634| - | - | - |
604| `Cd(~/code/*)` | `~/code/app` | `~/code/app/src`, `~/code` |635| `Cd(~/code/*)` | `~/code/app` | `~/code/app/src`, `~/code` |
605| `Cd(~/code/**)` | `~/code` et tout répertoire sous celui-ci | répertoires en dehors de `~/code` |636| `Cd(~/code/**)` | `~/code` et tout répertoire situé sous celui-ci | les répertoires situés en dehors de `~/code` |
606| `Cd(**/node_modules)` | tout répertoire `node_modules` à n'importe quelle profondeur sous le répertoire actuel | `node_modules/pkg` |637| `Cd(**/node_modules)` | tout répertoire `node_modules` à n'importe quelle profondeur sous le répertoire actuel | `node_modules/pkg` |
607 638
608<h2 id="extend-permissions-with-hooks">639<h2 id="extend-permissions-with-hooks">
622 653
623Consultez [Décider si vous faites confiance à un mod](/docs/fr/plugins/mods/overview#decide-whether-to-trust-a-mod), ou [Gérer les mods pour votre organisation](/docs/fr/plugins/mods/admin#know-what-happens-by-default) si vous déployez des paramètres gérés.654Consultez [Décider si vous faites confiance à un mod](/docs/fr/plugins/mods/overview#decide-whether-to-trust-a-mod), ou [Gérer les mods pour votre organisation](/docs/fr/plugins/mods/admin#know-what-happens-by-default) si vous déployez des paramètres gérés.
624 655
625Les outils MCP marqués [`requiresUserInteraction`](/docs/fr/mcp#require-approval-for-a-specific-tool) demandent également toujours une invite lorsqu'un hook retourne `"allow"`, tout comme les outils connecteur [que votre organisation a définis sur `ask`](/docs/fr/mcp#organization-controls-on-connector-tools) dans les sessions où ce paramètre atteint Claude Code.656Pour un [outil qui nécessite une interaction de l'utilisateur](/docs/fr/permission-modes#actions-no-mode-auto-approves), tel que `AskUserQuestion` ou un outil MCP marqué `requiresUserInteraction`, l'approbation `tool.check` d'un mod n'ignore pas l'invite. Nécessite Claude Code v2.1.292 ou une version ultérieure. Les outils MCP marqués [`requiresUserInteraction`](/docs/fr/mcp#require-approval-for-a-specific-tool) demandent également toujours une invite lorsqu'un hook retourne `"allow"`, tout comme les lectures depuis des [chemins réseau](#network-paths) et les outils connecteur [que votre organisation a définis sur `ask`](/docs/fr/mcp#organization-controls-on-connector-tools) dans les sessions où ce paramètre atteint Claude Code.
626 657
627Un hook de blocage prend également la priorité sur les règles d'autorisation. Un hook qui se termine avec le code 2 arrête l'appel d'outil avant que les règles d'autorisation ne soient évaluées, donc le blocage s'applique même lorsqu'une règle d'autorisation permettrait autrement l'appel. Pour exécuter toutes les commandes Bash sans invites sauf pour quelques-unes que vous voulez bloquer, ajoutez `"Bash"` à votre liste d'autorisation et enregistrez un hook PreToolUse qui rejette ces commandes spécifiques. Consultez [Bloquer les éditions des fichiers protégés](/docs/fr/hooks-guide#block-edits-to-protected-files) pour un script de hook que vous pouvez adapter.658Un hook de blocage prend également la priorité sur les règles d'autorisation. Un hook qui se termine avec le code 2 arrête l'appel d'outil avant que les règles d'autorisation ne soient évaluées, donc le blocage s'applique même lorsqu'une règle d'autorisation permettrait autrement l'appel. Pour exécuter toutes les commandes Bash sans invites sauf pour quelques-unes que vous voulez bloquer, ajoutez `"Bash"` à votre liste d'autorisation et enregistrez un hook PreToolUse qui rejette ces commandes spécifiques. Consultez [Bloquer les éditions des fichiers protégés](/docs/fr/hooks-guide#block-edits-to-protected-files) pour un script de hook que vous pouvez adapter.
628 659
636* **Pendant la session** : utilisez la commande `/add-dir`667* **Pendant la session** : utilisez la commande `/add-dir`
637* **Configuration persistante** : ajoutez à `additionalDirectories` dans les [fichiers de paramètres](/docs/fr/settings#where-settings-live)668* **Configuration persistante** : ajoutez à `additionalDirectories` dans les [fichiers de paramètres](/docs/fr/settings#where-settings-live)
638 669
639Les fichiers dans les répertoires supplémentaires suivent les mêmes règles d'autorisation que le répertoire de travail d'origine : ils deviennent lisibles sans invites, et les autorisations d'édition de fichiers suivent le mode d'autorisation actuel.670Les fichiers dans les répertoires supplémentaires suivent les mêmes règles de permission que le répertoire de travail d'origine : ils deviennent lisibles sans demande de permission, hormis la vérification des [chemins réseau](#network-paths), et les permissions d'édition de fichiers suivent le mode de permission actuel.
640 671
641Vous ne pouvez pas ajouter la plupart des [chemins réseau](/docs/fr/errors#working-directory-is-a-network-path), tels que le partage UNC `\\server\share`, comme répertoires de travail, car leur recherche peut contacter l'hôte qu'ils désignent. Sur Windows, mappez plutôt le partage à une lettre de lecteur et transmettez le lecteur avec `--add-dir` au lancement.672Vous ne pouvez pas ajouter la plupart des [chemins réseau](/docs/fr/errors#working-directory-is-a-network-path), tels que le partage UNC `\\server\share`, comme répertoires de travail, car leur recherche peut contacter l'hôte qu'ils désignent. Sur Windows, mappez plutôt le partage à une lettre de lecteur et transmettez le lecteur avec `--add-dir` au lancement.
642 673
648 Déplacer la session vers un autre répertoire679 Déplacer la session vers un autre répertoire
649</h3>680</h3>
650 681
651Pour déplacer la session vers un répertoire de travail principal différent, plutôt que d'[ajouter un répertoire](#working-directories) à côté du répertoire actuel, exécutez `/cd <path>`. Claude Code conserve la conversation, charge le `CLAUDE.md` du nouveau répertoire, et vous demande de [faire confiance à l'espace de travail](#project-allow-rules-and-workspace-trust) si vous n'y avez pas travaillé auparavant. Ensuite, Claude Code [trouve la session déplacée](/docs/fr/sessions#resume-a-session) lorsque vous exécutez `--resume` à partir du nouveau répertoire.682Pour déplacer la session vers un répertoire de travail principal différent, plutôt que d'[ajouter un répertoire](#working-directories) à côté du répertoire actuel, exécutez `/cd <path>`. Claude Code conserve la conversation, charge le `CLAUDE.md` du nouveau répertoire, et vous demande de [faire confiance à l'espace de travail](#project-allow-rules-and-workspace-trust) si vous n'y avez pas travaillé auparavant. Ensuite, Claude Code [trouve la session déplacée](/docs/fr/sessions#where-the-session-picker-looks) lorsque vous exécutez `--resume` à partir du nouveau répertoire.
652 683
653Dès que vous vous déplacez, Claude Code applique la configuration de projet du nouveau répertoire :684Dès que vous vous déplacez, Claude Code applique la configuration de projet du nouveau répertoire :
654 685
