Guide de Claude Code CLI : installation, configuration, commandes et variables d’environnement

En bref : Claude Code est un CLI agentique qui lit votre base de code, exécute des commandes et modifie des fichiers à travers un système à plusieurs niveaux de permissions, de hooks, d’intégrations MCP et de subagents. Maîtrisez cinq systèmes fondamentaux (configuration, permissions, hooks, MCP et subagents) et vous décuplerez votre productivité. Choisissez le niveau de modèle adapté à chaque tâche — Opus pour les raisonnements complexes, Sonnet pour le travail général, Haiku pour l’exploration rapide — ou utilisez systématiquement Opus si la qualité est votre seul critère. Utilisez des hooks (et non des prompts) pour tout ce qui doit toujours s’exécuter. Depuis le 14 août 2026, le mode Auto est le mode de permission par défaut des nouvelles sessions avec les offres Pro, Max et Team (annoncé le 7 août et vérifié en production le jour du basculement ; l’autonomie est contrôlée par un classificateur — une valeur defaultMode que vous avez définie reste en vigueur sauf si vous acceptez l’invite unique de changement, Shift+Tab permet de changer de mode dans n’importe quelle session et disableAutoMode le désactive dans toute l’organisation).²⁰³ Le modèle par défaut dépend de votre offre : Max, Team Premium, Enterprise (par siège depuis la v2.1.251) et le Anthropic API utilisent par défaut Claude Opus 5, tandis que Pro et Team Standard utilisent Sonnet 5 – contexte natif de 1M, 2 $/10 $ par MTok au tarif public standard (le tarif de lancement, initialement présenté comme temporaire, devient permanent : l’augmentation prévue le 1er septembre n’aura pas lieu)²²⁸²⁰⁷ – le choix de Sonnet 5 partout introduit par la v2.1.197 (30 juin 2026) appartient désormais au passé, et l’alias opus pointe vers Claude Opus 5 (v2.1.219+) ; la v2.1.198 (1er juillet) fait exécuter les subagents en arrière-plan par défaut, rend Claude dans Chrome accessible à tous, permet aux agents en arrière-plan de commit, push et ouvrir une PR en brouillon lorsqu’ils terminent du code dans un worktree, et déclenche le hook Notification (agent_needs_input/agent_completed) pour les sessions en arrière-plan ; la v2.1.199 (2 juillet) charge jusqu’à 5 invocations empilées de slash-skills et relance automatiquement les requêtes après des erreurs 429 temporaires pour les abonnés ; la v2.1.200 (3 juillet) renomme le mode de permission default en « Manual » dans le CLI, --help, VS Code et JetBrains (la valeur de configuration ne change pas et manual est accepté comme alias), et empêche les boîtes de dialogue AskUserQuestion de poursuivre automatiquement l’exécution par défaut ; la v2.1.202 (6 juillet) ajoute une option /config « Dynamic workflow size » et distingue /review <pr> (passe unique rapide) de /code-review <level> <pr#> — une séparation annulée par la v2.1.223 : /review redevient un alias de /code-review, et /code-review sans argument réutilise votre dernier niveau d’effort ; les v2.1.203 à 205 (7 au 9 juillet) renforcent le mode Auto — les fichiers de transcription sont protégés contre toute altération, rm -rf demande confirmation lorsque sa variable ne peut pas être résolue, et les notifications de tâches en arrière-plan précisent qu’aucune intervention humaine n’a eu lieu (afin d’empêcher l’exploitation de fausses approbations fabriquées dans la transcription) — et transforment /doctor en contrôle complet avec diagnostic et correction (alias /checkup).^181182183 La v2.1.217 (21 juillet) a fait marche arrière sur les subagents imbriqués — les subagents ont cessé de créer leurs propres subagents par défaut (un choix que la v2.1.219 a de nouveau inversé trois jours plus tard, en autorisant une profondeur de 3 ; voir ci-dessous), 20 subagents au maximum s’exécutent simultanément par défaut (CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS), et --max-budget-usd arrête désormais réellement les subagents en arrière-plan lorsque la limite est atteinte.¹⁹⁴ La v2.1.218 (22 juillet) confie /code-review à un subagent en arrière-plan — le travail de revue n’encombre plus votre conversation —, exécute par défaut les skills context: fork en arrière-plan (désactivation possible pour chaque skill avec background: false), ne lance /deep-research qu’en cas d’invocation explicite, confie au classificateur du mode Auto les vérifications portant sur les commandes rm dangereuses, l’opérateur d’arrière-plan & et les chemins Windows suspects au lieu d’afficher des boîtes de dialogue de permission, et empêche l’exécution des hooks déclarés dans le frontmatter des agents provenant de dossiers non approuvés.¹⁹⁵ La v2.1.219 (24 juillet) fait de Claude Opus 5 (claude-opus-5) le modèle Opus par défaut — contexte de 1M, sortie maximale de 128K, 5 $/25 $ par MTok (tarif identique à celui d’Opus 4.8), réflexion activée par défaut, effort réglé par défaut sur high, connaissances arrêtées en mai 2026 — et corrige deux réalités instaurées par les versions précédentes : le mode Fast s’applique désormais à Opus 5 et Opus 4.8 au tarif de 10 $/50 $ par MTok (2× le tarif de base, tandis qu’Opus 4.7 est entièrement retiré du mode Fast), et les subagents imbriqués sont de nouveau activés par défaut, avec une profondeur de 3 (CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 désactive l’imbrication). Cette même version ajoute l’événement de hook DirectoryAdded, le paramètre sandbox.network.strictAllowlist, une clé de paramètres workflowSizeGuideline, les workflows dynamiques adoptant désormais par défaut une recommandation de taille moyenne (visez moins de 15 agents), ainsi que la transmission des subagents imbriqués dans stream-json. La v2.1.220 (25 juillet) ne contient que des corrections de bugs et des améliorations de fiabilité. Les v2.1.221 à 226 (4 au 7 août) ajoutent la messagerie entre sessions (SendMessage/ListAgents entre vos sessions, sous macOS/Linux), les runners auto-hébergés pour les sessions cloud (Team/Enterprise), la source de plugin archive avec épinglage SHA-256, le masquage des identifiants JWT/SigV4 dans la sandbox, la vue Focus de VSCode et l’attribution d’un worktree propre aux copies créées avec /fork — tout en supprimant la limite de 200 subagents par session et ultraplan.^{199200201202196197198} Les v2.1.227 à 229 (10 au 12 août) sont principalement consacrées aux corrections, avec quelques améliorations pratiques : les marketplaces de plugins prennent en charge les sources command (un programme local affiche le dossier du plugin, qui est de nouveau résolu à chaque session ; mode: "link" l’utilise directement), claude remote-control --continue reprend votre session Remote Control la plus récente, ListAgents indique offline pour les pairs Remote Control déconnectés et cloud pour vos sessions cloud, /commit-push-pr cesse d’approuver automatiquement les options git dangereuses (--force, --amend, --no-verify), et l’outil Write applique les mêmes règles qu’Edit avec les modèles récents — l’écrasement d’un fichier non lu ne nécessite plus de lecture préalable pendant la session.^235233234 La v2.1.232 (13 août) fait du fork des subagents le comportement par défaut (subagent_type: "fork" hérite de l’intégralité de la conversation et du cache du prompt ; dans les sessions interactives, les créations d’agents qui ne sont pas des coéquipiers s’exécutent en arrière-plan), vous permet de mentionner avec @ une autre session active par son nom dans le prompt (Claude achemine le message via SendMessage, et un nom seul correspondant exactement à une session active est désormais accepté sans confirmation de référence), garantit l’unicité des noms de sessions interactives sur chaque machine (variantes name-word-word), expose les contrôles de réception entre sessions sous forme de lignes dans /config et établit la parité avec GitLab — neuf familles de jetons GitLab sont masquées dans la sandbox, les identifiants du CLI glab sont protégés et les URL de marketplace gitlab.com simples (y compris avec des sous-groupes imbriqués) sont clonées comme celles de GitHub.²³² La v2.1.233 (14 août) étend la parité GitLab à --worktree (URL de MR, affichées sous la forme !N dans claude agents), ajoute sous Linux des limites de mémoire pour les commandes Bash (CLAUDE_CODE_TOOL_MEMORY_LIMIT) ainsi qu’un réglage du TTL du cache WebFetch, et désactive par défaut les outils de suivi des tâches et des listes de choses à faire avec Opus 4.8, Sonnet 5, Fable 5 et les modèles ultérieurs (CLAUDE_CODE_ENABLE_TODO_TOOLS=1 les réactive) — elle annule également une partie des changements de la v2.1.232 relatifs aux permissions Bash sous Windows après une régression du mode Auto.²³¹ La v2.1.234 (17 août) permet à Claude Code de reprendre automatiquement votre session après la réinitialisation d’une limite d’utilisation de claude.ai (désactivation dans /config : « Continue automatically at usage limit »), autorise l’ouverture de /permissions et /add-dir en cours d’exécution, ajoute CLAUDE_CODE_PROJECT_DIR_NAME ainsi qu’un point de contrôle /goal pour les tâches en arrière-plan (CLAUDE_CODE_GOAL_CHECKIN_MINUTES), affiche un badge de MR GitLab (!N) dans le pied de page des dépôts disposant d’un CLI glab authentifié, et réduit le coût contextuel du skill intégré claude-api d’environ 200k à environ 25k tokens grâce au chargement à la demande de la documentation de référence.²³⁰ Les v2.1.235 à 238 (18 au 20 août) ajoutent un style de sortie intégré « Concise » (résultats en premier, sans préambule ni narration — sélectionnez-le dans Output style sous /config), la variable d’environnement ANTHROPIC_DEFAULT_MODEL (elle définit le modèle utilisé au démarrage des nouvelles sessions ; un choix effectué avec /model reste prioritaire et persistant, contrairement à ANTHROPIC_MODEL), un paramètre facultatif spellcheck (qui souligne les mots mal orthographiés dans le prompt à l’aide de votre installation de aspell, hunspell ou ispell), un paramètre keybindingFlavor ("readline" fait en sorte que Ctrl+W efface jusqu’à l’espace précédent, comme dans Bash ; ce paramètre a été retiré dans la v2.1.261 – readline est désormais le seul comportement), headersHelper dans les marketplaces de plugins et le fichier .mcp.json du projet (une commande génère des en-têtes HTTP à courte durée de vie ; les helpers des entrées de catalogue ne s’exécutent qu’à l’installation ou à la mise à jour après affichage de leur commande, tandis que les helpers de portée projet/plugin/agent s’exécutent sans hériter des variables d’environnement contenant les identifiants, après la boîte de dialogue d’approbation du dossier), notify_when_idle dans SendMessage entre sessions (une notification unique lorsque l’autre session locale redevient inactive), ainsi que deux modifications du comportement des permissions : le mode Auto ignore désormais les règles d’autorisation Monitor (les commandes Monitor sont soumises au même contrôle du classificateur que Bash), et sous macOS, les règles génériques de refus de lecture dans la sandbox (**/.env) prévalent au sein des zones dont la lecture est autorisée et ne peuvent pas être contournées en renommant le fichier refusé — le classificateur du mode Auto utilisant désormais les valeurs par défaut de Claude API sur Bedrock, Vertex AI et Foundry, ainsi que lorsque la télémétrie est désactivée²²³ (depuis la v2.1.273, ces passerelles utilisent le classificateur local par défaut « pour le moment » – CLAUDE_CODE_AUTO_MODE_SERVER=1 active le classificateur côté serveur de la plateforme²¹⁷). La v2.1.239 (21 août) ajoute /claude-api upgrade (migration des projets Python de anthropic 0.x vers 1.x), intègre aux estimations de coût la majoration de 1,1× pour l’inférence exclusivement américaine dans les espaces de travail soumis à des exigences de résidence des données (/cost, ligne d’état, --max-budget-usd), apporte la messagerie entre sessions à Windows, affiche les plugins synchronisés avec claude.ai sous la forme name@synced (ils peuvent être gérés avec claude plugin enable/disable et ne remplacent jamais une installation locale du même nom), indique à ListAgents le nom de la session elle-même et ses coéquipiers actifs, étend "readline" aux raccourcis de navigation par mot de Bash, espace davantage les points de contrôle /goal (30 min → 1 h → 2 h) et propose le moteur de rendu plein écran sur Bedrock/Vertex/Foundry ; les v2.1.240 à 241 (22 et 23 août) corrigent des bugs. La synthèse documentaire de la même semaine signale deux changements de statut : /design — un skill en aperçu de recherche qui publie, via artifacts, un canevas de plans de travail d’interface modifiables (Pro/Max/Team/Enterprise, nécessite la v2.1.233+) — et la sortie de Remote Control de l’aperçu de recherche, les machines exécutant claude remote-control apparaissant sous forme de cartes d’appareil dans l’application Claude.²⁰⁵ Depuis les v2.1.174 à 176 (12 juin 2026), la liste d’autorisation availableModels peut désormais restreindre le modèle Default grâce au nouveau paramètre administré enforceAvailableModels (les paramètres utilisateur ou projet ne peuvent pas élargir une liste administrée), les titres de session sont générés dans la langue de votre conversation (fixez-en une avec le paramètre language), tandis que les nouveaux paramètres footerLinksRegexes et wheelScrollAccelerationEnabled, une boîte de dialogue d’attribution /usage dans VSCode et une correction permettant aux conditions if des hooks de reconnaître les motifs de chemin Read/Edit/Write complètent cette version.¹⁷² Depuis la v2.1.173 (11 juin 2026), un nom de modèle Fable 5 doté du suffixe [1m] est automatiquement normalisé et ce suffixe est supprimé — Fable 5 inclut déjà un contexte de 1M par défaut, ce suffixe est donc inutile (il n’a jamais eu de sens que pour Opus/Sonnet). Depuis la v2.1.172 (10 juin 2026), les sub-agents pouvaient créer récursivement leurs propres sub-agents, jusqu’à 5 niveaux de profondeur — un comportement par défaut conservé jusqu’à la v2.1.216, puis désactivé dans la v2.1.217 (voir ci-dessus) —, Bedrock lit sa région depuis ~/.aws lorsque AWS_REGION n’est pas défini (/status en indique la source), /plugin ajoute une barre de recherche pour la marketplace et la métrique OTEL claude_code.lines_of_code.count reçoit un attribut model. Depuis la v2.1.170 (9 juin 2026), Claude Fable 5 — un nouveau niveau de modèle supérieur à Opus — peut être sélectionné dans Claude Code avec /model fable après claude update (il prend en charge toute l’échelle d’effort de low à max, mais sa réflexion ne peut pas être désactivée) ; Opus 4.8 reste le modèle agentique par défaut. Depuis la v2.1.169 (8 juin 2026), --safe-mode (et CLAUDE_CODE_SAFE_MODE) lance une session vierge dont toutes les personnalisations sont désactivées à des fins de dépannage, /cd déplace une session vers un nouveau répertoire de travail sans perturber le cache du prompt, et disableBundledSkills masque au modèle les skills et slash commands intégrés. Depuis la v2.1.166 (6 juin 2026), un paramètre fallbackModel enchaîne jusqu’à trois modèles de secours lorsque le modèle principal est surchargé, le glob "*" fonctionne dans les règles de refus MCP, et MAX_THINKING_TOKENS=0 / --thinking disabled désactivent entièrement la réflexion sur les modèles qui l’activent par défaut. Depuis la v2.1.154 (28 mai 2026), Opus 4.8 est le nouveau modèle par défaut, avec un effort élevé par défaut et un niveau /effort xhigh, les workflows dynamiques orchestrent des dizaines ou des centaines d’agents en arrière-plan via /workflows, le mode Fast d’Opus 4.8 coûte 2× le tarif standard pour une vitesse multipliée par 2,5, le prompt système allégé est désormais utilisé par défaut pour tous les modèles à l’exception de Haiku/Sonnet/Opus 4.7 et antérieurs, /simplify est revenu à une simple revue de nettoyage (distincte de /code-review --fix), claude agents accepte ! <command> pour créer des sessions shell en arrière-plan, les plugins peuvent déclarer defaultEnabled: false, l’exécution en streaming des outils est toujours activée, et les serveurs MCP stdio reçoivent CLAUDE_CODE_SESSION_ID ainsi que CLAUDECODE=1 dans leur environnement. La v2.1.153 a ajouté skipLfs aux marketplaces de plugins, fait de la sélection effectuée avec /model la valeur par défaut enregistrée (appuyez sur s pour l’appliquer uniquement à la session) et ajouté COLUMNS/LINES à l’environnement de la ligne d’état. La v2.1.152 a introduit /code-review --fix (qui applique les conclusions à l’arbre de travail), disallowed-tools dans le frontmatter des skills, /reload-skills, le nouvel événement de hook MessageDisplay, les sorties reloadSkills/sessionTitle du hook SessionStart, le paramètre administré pluginSuggestionMarketplaces, le changement de --fallback-model en cours de session, et supprimé l’activation volontaire du mode Auto.^{162 163 164 165 166 167 168 169 170 244 171}

Claude Code fonctionne comme un système agentique, et non comme une interface de chat dotée de connaissances en programmation. Le CLI lit votre base de code, exécute des commandes, modifie des fichiers, gère les workflows git, se connecte à des services externes via MCP et délègue les tâches complexes à des subagents spécialisés. Tout passe par une interface en ligne de commande qui s’intègre aux méthodes de travail réelles des développeurs. En février 2026, 4 % des commits GitHub publics (environ 135 000 par jour) sont produits par Claude Code — soit une croissance de 42 896× en 13 mois depuis l’aperçu de recherche — et 90 % du propre code de Anthropic est écrit par une IA.¹⁰³

La différence entre un usage occasionnel et un usage efficace de Claude Code repose sur cinq systèmes fondamentaux. Maîtrisez-les et Claude Code décuplera votre efficacité :

1. Hiérarchie de configuration : contrôle le comportement
2. Système de permissions : contrôle les opérations
3. Système de hooks : permet une automatisation déterministe
4. Protocole MCP : étend les capacités
5. Système de subagents : prend en charge les tâches complexes en plusieurs étapes

Points clés

• Cinq systèmes déterminent votre efficacité : la hiérarchie de configuration, les permissions, les hooks, MCP et les subagents contrôlent tout, du comportement à l’automatisation.
• Confiez le travail à la couche de délégation : les subagents évitent de saturer le contexte en isolant l’exploration dans des fenêtres de contexte vierges et en ne renvoyant que des synthèses.
• Les hooks garantissent l’exécution, contrairement aux prompts : utilisez des hooks pour le linting, le formatage et les contrôles de sécurité qui doivent s’exécuter systématiquement, quel que soit le comportement du modèle.
• La répartition entre niveaux de modèles réduit les coûts sans sacrifier la qualité : confiez l’exploration des subagents à des modèles moins coûteux et réservez Opus aux véritables raisonnements d’architecture — ou utilisez systématiquement Opus si la qualité est votre seul critère.
• MCP connecte Claude à votre chaîne d’outils : les bases de données, GitHub, Sentry et plus de 3 000 intégrations étendent les capacités de Claude au-delà de la lecture de fichiers et des commandes bash.

J’ai passé des mois à pousser Claude Code dans ses retranchements sur des bases de code en production, des pipelines CI/CD et des déploiements en entreprise. Ce guide condense cette expérience dans la référence complète que j’aurais aimé trouver à mes débuts. Chaque fonctionnalité comprend la syntaxe exacte, des exemples de configuration réels et les cas limites qui piègent même les utilisateurs expérimentés.

Choisissez votre parcours

Comment utiliser ce guide

Cette référence compte plus de 5 000 lignes — vous n’avez pas besoin de la lire intégralement. Commencez par la section qui correspond à votre niveau d’expérience :

Utilisez Ctrl+F / Cmd+F dans votre navigateur pour rechercher des options, des commandes ou des clés de configuration précises. La fiche de référence rapide, à la fin, offre une synthèse facile à parcourir de toutes les commandes principales.

Analyses approfondies associées

Ces articles de blog explorent en détail certains aspects de Claude Code :

Démarrage rapide en 60 secondes

Si vous souhaitez simplement lancer Claude Code et voir le résultat, procédez dans cet ordre :

# 1. Install (pick one)
npm install -g @anthropic-ai/claude-code          # npm users
brew install anthropic/claude/claude              # macOS + Homebrew
curl -sL claude.ai/install.sh | sh                # native installer

# 2. Launch in any project directory
cd ~/your-project && claude

# 3. Authenticate (browser opens automatically on first run)
/login

# 4. Ask your first question
> What does this repo do? Read the key files and summarize.

C’est tout. La suite détaille les options d’installation, la configuration des autorisations et des hooks, la connexion des serveurs MCP et le déploiement en entreprise — mais rien de tout cela n’est nécessaire pour commencer.

Prérequis : Node 22+ uniquement pour l’ancienne méthode via npm (version minimale relevée de 18 à partir de la v2.1.198 ; la documentation d’installation actuelle indique « Node.js 22 ou version ultérieure », vérifié le 7 août 2026) ; le programme d’installation natif recommandé ne dépend pas de Node. macOS / Linux / Windows 10+ sont pris en charge. Un abonnement Claude Pro, Max, Team ou Enterprise, ou une clé Anthropic API avec facturation à l’usage, couvre l’utilisation. Consultez Comment installer Claude Code ? pour connaître les spécificités de chaque plateforme, les procédures de dépannage et la méthode utilisant le binaire natif (adoptée par défaut depuis la v2.1.113). Les informations relatives à la dernière version présentées dans ce guide sont actualisées à chaque publication ; consultez la ligne la plus récente du journal des modifications pour connaître la date de la dernière vérification.²⁴⁴

Fonctionnement de Claude Code : le modèle mental

Avant d’examiner les fonctionnalités, vous devez comprendre comment l’architecture de Claude Code façonne toutes vos interactions avec l’outil. Le système repose sur trois couches :

┌─────────────────────────────────────────────────────────┐
│                    CLAUDE CODE LAYERS                    │
├─────────────────────────────────────────────────────────┤
│  EXTENSION LAYER                                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐    │
│  │   MCP   │  │  Hooks  │  │ Skills  │  │ Plugins │    │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘    │
│  External tools, deterministic automation, domain       │
│  expertise, packaged extensions                          │
├─────────────────────────────────────────────────────────┤
│  DELEGATION LAYER                                        │
│  ┌─────────────────────────────────────────────────┐    │
│  │           Subagents (20 concurrent default)      │    │
│  │   Explore | Plan | General-purpose | Custom      │    │
│  └─────────────────────────────────────────────────┘    │
│  Isolated contexts for focused work, returns summaries  │
├─────────────────────────────────────────────────────────┤
│  CORE LAYER                                              │
│  ┌─────────────────────────────────────────────────┐    │
│  │         Main Conversation Context                │    │
│  │   Tools: Read, Edit, Bash, Glob, Grep, etc.     │    │
│  └─────────────────────────────────────────────────┘    │
│  Your primary interaction; limited context; costs money │
└─────────────────────────────────────────────────────────┘

Couche principale : votre conversation principale. Chaque message, lecture de fichier et résultat d’outil consomme une partie du contexte d’une fenêtre partagée (200 000 tokens en standard⁹¹, 1 million de tokens avec Opus 4.6 ou les modèles à contexte étendu). Lorsque cette fenêtre est pleine, Claude perd le fil des décisions antérieures et la qualité se dégrade. Cette couche est facturée au token.

Couche de délégation : les subagents démarrent avec un contexte vierge, accomplissent une tâche ciblée et renvoient une synthèse. Les résultats de leurs recherches n’alourdissent pas votre conversation principale ; seules leurs conclusions y sont intégrées. Confiez les recherches à des subagents utilisant des modèles moins coûteux, ou conservez votre modèle principal pour toutes les tâches si la qualité prime sur le coût.

Couche d’extension : MCP connecte des services externes (bases de données, GitHub, Sentry). Les hooks garantissent l’exécution de commandes shell indépendamment du comportement du modèle. Les skills formalisent une expertise métier que Claude applique automatiquement. Les plugins regroupent tous ces éléments afin de les distribuer.

L’idée essentielle : la plupart des utilisateurs travaillent exclusivement dans la couche principale, tandis que le contexte s’alourdit et que les coûts augmentent. Les utilisateurs expérimentés confient les recherches et les tâches spécialisées à la couche de délégation, configurent la couche d’extension selon leur flux de travail et réservent la couche principale à l’orchestration et aux décisions finales.

Table des matières

1. Comment installer Claude Code ?
2. Démarrage rapide : votre première session
3. Principaux modes d’interaction
4. Analyse approfondie du système de configuration
5. Quel modèle choisir ?
6. Combien coûte Claude Code ?
7. Cadres de décision
8. Comment fonctionne le système d’autorisations ?
9. Comment fonctionnent les hooks ?
10. Qu’est-ce que MCP (Model Context Protocol) ?
11. Que sont les subagents ?
12. Qu’est-ce que le mode de réflexion étendue ?
13. Styles de sortie
14. Slash commands
15. Comment fonctionnent les skills ?
16. Système de plugins
17. Comment fonctionne la mémoire ?
18. Images et entrées multimodales
19. Mode vocal
20. Comment fonctionne l’intégration à Git ?
21. Comment utiliser Claude Code dans mon IDE ?
22. Modes d’utilisation avancés
23. Agents distants et en arrière-plan [APERÇU DE RECHERCHE]
24. Claude dans Chrome
25. Claude Code dans Slack [APERÇU DE RECHERCHE]
26. Claude Code sur le Web [APERÇU DE RECHERCHE]
27. Claude dans Microsoft 365 (mai 2026)
28. Optimisation des performances
29. Comment résoudre les problèmes ?
30. Déploiement en entreprise
31. Référence des raccourcis clavier
32. Bonnes pratiques
33. Recettes de flux de travail
34. Guide de migration
35. Conseils adaptés à chaque public
36. Fiche de référence rapide
37. Journal des modifications
38. Références

Comment installer Claude Code ?

Configuration requise

Claude Code fonctionne sous macOS 13+, Ubuntu 20.04+/Debian 10+ et Windows 10+ (en natif ou avec WSL). Le système nécessite au minimum 4 Go de RAM et une connexion Internet active.⁹² La compatibilité avec le shell est optimale avec Bash, Zsh ou Fish.

Sous Windows, WSL 1 et WSL 2 sont tous deux pris en charge. Git Bash fonctionne également si vous préférez utiliser Windows en natif. Alpine Linux et les autres systèmes basés sur musl nécessitent des paquets supplémentaires :

apk add libgcc libstdc++ ripgrep
export USE_BUILTIN_RIPGREP=0

Matrice de prise en charge des plateformes

Installation, mise à jour et désinstallation en un coup d’œil

Tableau de référence rapide — toutes les méthodes, toutes les commandes et la vérification de la version sur un seul écran. Les sous-sections suivantes détaillent chaque méthode et la résolution des problèmes.

Depuis la v2.1.113, le CLI canonique lance un binaire Claude Code natif par l’intermédiaire d’une dépendance facultative propre à chaque plateforme, au lieu d’un JavaScript intégré — utilisez le programme d’installation natif pour bénéficier de la distribution testée. La méthode npm fonctionne toujours, mais affiche l’avis d’obsolescence introduit initialement dans la v2.1.15.

Méthodes d’installation

Installation native (recommandée)

Le binaire natif offre l’expérience la plus simple, sans dépendance à Node.js :

# macOS and Linux
curl -fsSL https://claude.ai/install.sh | bash

# Homebrew alternative
brew install --cask claude-code

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# Windows CMD
curl -fsSL https://claude.ai/install.cmd -o install.cmd && install.cmd && del install.cmd

Pour installer une version particulière :

# Install specific version
curl -fsSL https://claude.ai/install.sh | bash -s 1.0.58

# Install latest explicitly
curl -fsSL https://claude.ai/install.sh | bash -s latest

# Windows PowerShell - specific version
& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 1.0.58

Installation avec npm (obsolète)

Remarque : depuis la v2.1.15, les installations effectuées avec npm affichent un avis d’obsolescence. Le binaire natif constitue désormais la méthode d’installation recommandée. Effectuez la migration avec claude install.

Pour les anciens environnements dans lesquels npm reste nécessaire :

npm install -g @anthropic-ai/claude-code

N’utilisez jamais sudo pour une installation avec npm. Cela crée des problèmes d’autorisations qui compliquent toutes les étapes ultérieures.

Migration depuis une installation existante

Si vous disposez d’une ancienne installation basée sur npm, migrez vers le binaire natif :

claude install

Options d’authentification

Claude Code prend en charge trois méthodes d’authentification, chacune présentant des avantages et des inconvénients différents :

Console Claude (facturation API)

Connectez-vous directement au API de Anthropic via platform.claude.com (anciennement console.anthropic.com). Créez un compte, configurez la facturation et authentifiez-vous à l’aide du CLI. La Console propose une facturation à l’usage avec un accès complet au API. Un espace de travail « Claude Code » dédié est créé automatiquement ; vous ne pouvez pas créer de clés API pour cet espace de travail, mais vous pouvez en surveiller l’utilisation. Depuis la v2.1.243, /login → Console Anthropic propose une méthode sans clé, « Se connecter avec votre compte Console » (recommandée), en complément de la création d’une clé API. Les organisations qui n’autorisent pas les clés API peuvent ainsi se connecter avec leurs identifiants Console.²²⁷

Abonnement Pro ou Max à Claude

Utilisez les identifiants de votre compte claude.ai. L’abonnement couvre à la fois l’interface web et l’utilisation du CLI dans le cadre d’une seule formule mensuelle. Il simplifie la facturation pour les utilisateurs individuels qui souhaitent maîtriser leurs coûts.

Plateformes d’entreprise

AWS Bedrock, Google Vertex AI et Microsoft Foundry offrent chacun un accès adapté aux entreprises, intégré aux relations de facturation cloud existantes. Assistant de configuration de Bedrock (v2.1.92+) : un assistant interactif accessible depuis l’écran de connexion vous guide dans l’authentification AWS, la sélection de la région, la vérification des identifiants et l’épinglage du modèle.¹³⁷ Assistant de configuration de Vertex AI (v2.1.98+) : un assistant équivalent pour Google Cloud vous guide dans l’authentification GCP, la configuration du projet et de la région, la vérification des identifiants et l’épinglage du modèle.¹⁴² Fédération des identités de workload mTLS de Vertex AI (v2.1.121+) : Vertex AI accepte désormais la fédération des identités de workload fondée sur des certificats X.509 (identifiants par défaut de l’application mTLS) — des jetons GCP à courte durée de vie générés à partir d’un certificat client, sans JSON de compte de service.¹⁵⁴ Approbation des certificats d’autorité de certification du système d’exploitation (v2.1.101+) : les proxys TLS d’entreprise fonctionnent désormais par défaut — Claude Code fait confiance au magasin de certificats du système d’exploitation. Définissez CLAUDE_CODE_CERT_STORE=bundled pour utiliser uniquement les autorités de certification intégrées.¹⁴³

# AWS Bedrock
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=us-east-1
export AWS_PROFILE=your-profile

# Google Vertex AI
export CLAUDE_CODE_USE_VERTEX=1
export CLOUD_ML_REGION=us-east5
export ANTHROPIC_VERTEX_PROJECT_ID=your-project

# Microsoft Foundry
export CLAUDE_CODE_USE_FOUNDRY=1
export ANTHROPIC_FOUNDRY_RESOURCE=your-resource-name
# Optional: API key auth (otherwise uses Entra ID)
export ANTHROPIC_FOUNDRY_API_KEY=your-key

# Amazon Bedrock via Mantle (v2.1.94+)
export CLAUDE_CODE_USE_MANTLE=1

Pour les déploiements d’entreprise derrière des proxys ou passant par des passerelles LLM :

# Corporate proxy
export HTTPS_PROXY='https://proxy.example.com:8080'

# LLM gateway (skip native auth)
export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_BEDROCK_BASE_URL='https://your-gateway.com/bedrock'
export CLAUDE_CODE_SKIP_BEDROCK_AUTH=1

En-têtes d’indication pour les passerelles (v2.1.273, activation facultative) : lorsque CLAUDE_CODE_GATEWAY_HINT_HEADERS=1 est défini, Claude Code ajoute cinq en-têtes de requête qu’une passerelle LLM peut utiliser pour le routage et l’observabilité : x-claude-code-request-class, x-claude-code-agent-type, x-claude-code-prev-tool-durations, x-claude-code-compaction et x-claude-code-context-compacted.²¹⁷

Vérification

claude doctor

La commande indique le type d’installation, la version, la configuration du système et les éventuels problèmes détectés.

Gestion de l’authentification (v2.1.41+)

Gérez l’authentification sans ouvrir le REPL :⁹⁰

claude auth login          # Log in or switch accounts
claude auth status         # Check current auth state (account, plan, expiry)
claude auth logout         # Clear stored credentials

Depuis la v2.1.268, claude auth status --json inclut configDirectory — le dossier de configuration effectivement lu par le CLI, ce qui s’avère utile lorsque l’indirection de CLAUDE_CONFIG_DIR crée une ambiguïté.²¹⁶

Depuis la v2.1.273, la connexion avec un compte Claude demande également l’accès à vos plugins claude.ai.²¹⁷

Procédure courante pour passer d’un compte ou d’une organisation à l’autre :

claude auth logout && claude auth login

Voir également : Comment résoudre les problèmes ? pour résoudre les échecs d’authentification.

Mises à jour

Claude Code se met à jour automatiquement par défaut, en recherchant les mises à jour au démarrage et régulièrement pendant les sessions. Les mises à jour sont téléchargées en arrière-plan et appliquées au prochain lancement.

Pour désactiver les mises à jour automatiques :

export DISABLE_AUTOUPDATER=1

Ou dans settings.json :

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

Mise à jour manuelle :

claude update

Désinstallation

Installation native (macOS/Linux/WSL) :

rm -f ~/.local/bin/claude
rm -rf ~/.claude-code

Installation native (Windows PowerShell) :

Remove-Item -Path "$env:LOCALAPPDATA\Programs\claude-code" -Recurse -Force
Remove-Item -Path "$env:LOCALAPPDATA\Microsoft\WindowsApps\claude.exe" -Force

Nettoyage de la configuration (supprime tous les paramètres) :

rm -rf ~/.claude
rm ~/.claude.json
rm -rf .claude
rm -f .mcp.json

Démarrage rapide : votre première session

1. Installez et lancez :

claude                           # Launch in current directory

2. Accédez à un projet :

cd ~/my-project && claude        # Or launch from any git repo

3. Demandez à Claude d’effectuer une tâche :

> "Explain the architecture of this project"
> "Find all TODO comments and create a summary"
> "Add input validation to the signup form"

4. Utilisez les raccourcis clavier pendant votre session :

/cost                            # Check token usage and cost
/compact                         # Free up context when it gets large
Alt+T                            # Toggle extended thinking for hard problems
Ctrl+C                           # Cancel current response

5. Reprenez plus tard :

claude -c                        # Resume your most recent session
claude --resume                  # Pick from session list

Conseil d’expert : créez un fichier CLAUDE.md à la racine de votre projet avec les commandes de build, les conventions de codage et des notes sur l’architecture. Claude le lit à chaque session — c’est le moyen le plus efficace d’améliorer la qualité.

Modes d’interaction principaux

REPL interactif

Lancez Claude Code sans argument pour accéder à la boucle interactive de lecture-évaluation-affichage :

cd your-project
claude

Le REPL conserve le contexte de la conversation d’un échange à l’autre. Saisissez directement vos requêtes, recevez les réponses, puis poursuivez jusqu’à ce que vous quittiez la session avec /exit ou Ctrl+D.

Commencez par une requête initiale pour cibler la session :

claude "explain the authentication flow in this project"

Conseil d’expert : Le REPL conserve son état lors des opérations de compactage. Lorsque le contexte devient trop volumineux, Claude résume automatiquement les échanges plus anciens tout en préservant les décisions importantes et les extraits de code. Vous pouvez déclencher cette opération manuellement avec /compact ou ajouter des instructions personnalisées sur les éléments à conserver.

Mode non interactif

Le mode d’affichage (-p) exécute une seule requête, puis se ferme :

# Direct query
claude -p "list all TODO comments in this project"

# Process piped input
cat error.log | claude -p "identify the root cause of these failures"

# Chain with other tools
claude -p "generate a README" > README.md

Pour obtenir une sortie structurée adaptée à l’analyse dans des scripts :

claude -p "count lines by file type" --output-format json

La sortie JSON contient tout ce dont vous avez besoin pour l’automatisation :

{
  "type": "result",
  "subtype": "success",
  "total_cost_usd": 0.0034,
  "is_error": false,
  "duration_ms": 2847,
  "duration_api_ms": 1923,
  "num_turns": 4,
  "result": "Response text here...",
  "session_id": "abc-123-def"
}

Pour traiter en temps réel une sortie diffusée en continu :

claude -p "build the application" --output-format stream-json | while read line; do
  echo "$line" | jq -r 'select(.result) | .result'
done

Options de format de sortie :

Texte des subagents dans stream-json (v2.1.211+) : Par défaut, la sortie stream-json ne contient que les événements de la session principale — le travail effectué dans les subagents apparaît sous forme de résumé. L’indicateur --forward-subagent-text (ou CLAUDE_CODE_FORWARD_SUBAGENT_TEXT=1) transmet également à ce flux le texte et le raisonnement des subagents. Les systèmes d’orchestration et les pipelines de journaux peuvent ainsi observer le travail délégué à mesure qu’il progresse, au lieu de ne voir que le rapport final.¹⁸⁸

Les subagents imbriqués sont désormais également transmis (v2.1.219). À l’origine, seuls les subagents de profondeur 1 apparaissaient. Les subagents créés à une profondeur de 2 ou plus figurent désormais eux aussi dans le flux transmis, chacun étant associé à l’identifiant tool_use de l’appel Agent qui l’a créé. Un pipeline peut donc reconstruire l’arborescence de délégation au lieu de recevoir une simple liste de textes. Cette évolution va de pair avec le rétablissement, dans la même version, de la création imbriquée jusqu’à une profondeur de 3 par défaut : sans cela, deux des trois niveaux seraient restés invisibles.¹⁹⁶

Les subagents passés en arrière-plan ne deviennent plus silencieux (v2.1.273) : Les sorties SDK et stream-json ne perdent plus les messages restants ni le rapport final d’un subagent lorsque celui-ci est déplacé en arrière-plan en cours d’exécution (par exemple par CLAUDE_AUTO_BACKGROUND_TASKS).²¹⁷

Codes de sortie :

Contrôle du comportement agentique en mode -p :

# Limit autonomous turns (prevents runaway loops)
claude -p "refactor the auth module" --max-turns 10

# Allow specific tools without prompting
claude -p "fix lint errors" --allowedTools "Edit,Bash(npm run lint)"

# Use with a specific model
claude -p "explain this code" --model claude-sonnet-5

# Bare mode: skip hooks, LSP, plugin sync, skill walks (v2.1.81+)
claude -p "count files" --bare

# Channel permission relay: send approval prompts to Telegram/Discord (v2.1.81+)
claude --channels

# Restricted mode for eval harnesses and shared machines (v2.1.248+)
claude --restricted -p "query" --tools "Read,Grep,Glob"

# Unattended hosts: deny anything that would prompt (v2.1.259+)
claude -p "run the nightly checks" --permission-prompts none

Mode restreint (v2.1.248+) : --restricted (ou CLAUDE_CODE_RESTRICTED=1) est conçu pour les systèmes d’évaluation qui pilotent claude sur une machine partagée. Il supprime les outils intégrés qui exécutent des commandes ou du code, ainsi que WebFetch, sauf si vous les indiquez individuellement dans --tools — le préréglage default ne suffit pas —, limite les outils intégrés de gestion de fichiers aux répertoires de travail, ne charge que les paramètres administrés et --settings (les fichiers de paramètres utilisateur, de projet et locaux sont ignorés), refuse bypassPermissions et interdit la création de sessions cloud.²⁰⁶²⁰⁹

--permission-prompts none (v2.1.259) : le complément destiné aux hôtes sans surveillance. Toute action qui déclencherait une demande d’autorisation est automatiquement refusée, tandis que le mode d’autorisation actif — mode automatique compris — continue de prendre toutes les décisions qu’il peut prendre sans votre intervention. Ne le confondez pas avec --permission-prompt-tool, qui délègue les demandes à un outil MCP au lieu de les refuser. La référence CLI ne mentionne pas encore ce nouvel indicateur ; le CHANGELOG fait foi.²¹¹

cd persiste d’un échange à l’autre dans les sessions non interactives (v2.1.265) : Les sessions -p alimentées par une entrée stream-json, les sessions Agent SDK et les sessions cloud ne réinitialisent plus le répertoire de travail du shell à chaque nouveau message utilisateur — un cd effectué lors d’un échange reste donc actif lors du suivant.²¹⁵

--system-prompt-snapshot off (v2.1.267) : Par défaut, une conversation réutilise à chaque requête le prompt système enregistré. Cet indicateur régénère plutôt le prompt système à chaque requête. Il sert à itérer sur le texte du prompt, lorsque chaque exécution doit prendre en compte votre dernière modification plutôt que l’instantané, au détriment de la stabilité du cache de prompts que cet instantané vise à préserver.²¹⁶

Modèle d’intégration CI/CD :

# In a GitHub Action or CI pipeline
result=$(claude -p "review this diff for security issues" --output-format json 2>/dev/null)
is_error=$(echo "$result" | jq -r '.is_error')
if [ "$is_error" = "true" ]; then
  echo "Review failed"
  exit 1
fi
echo "$result" | jq -r '.result'

Gestion des sessions

Les sessions conservent l’historique des conversations afin de pouvoir les poursuivre. Cette persistance est essentielle pour les travaux complexes répartis sur plusieurs sessions :

# Continue most recent session
claude -c

# Continue with additional prompt
claude -c -p "now add error handling"

# Resume specific session by ID
claude -r "abc123" "implement the remaining tests"

# Fork a session for parallel exploration
claude -r "base-session" --fork-session "try a different approach"

Déplacer une session en cours avec /cd (v2.1.169+ ; configuration immédiate depuis la v2.1.246) : /cd path modifie le répertoire de travail sans invalider le cache de prompts. Depuis la v2.1.246, les paramètres de projet, hooks, serveurs .mcp.json (soumis à la demande d’autorisation habituelle), skills et agents du nouveau répertoire prennent effet immédiatement après le déplacement, au lieu d’attendre --resume.²³⁹²²⁶

Sessions liées aux PR (v2.1.27+, étendues en v2.1.119+) : Démarrez une session liée à une pull request ou merge request précise. Depuis la v2.1.119, --from-pr accepte les URL de MR GitLab, de PR Bitbucket et de PR GitHub Enterprise, en plus de celles de github.com :⁷⁴¹⁵²

claude --from-pr 123                                                # GitHub PR number (assumes current repo's remote)
claude --from-pr https://github.com/org/repo/pull/123               # GitHub URL
claude --from-pr https://gitlab.com/org/repo/-/merge_requests/45    # GitLab MR (v2.1.119+)
claude --from-pr https://bitbucket.org/org/repo/pull-requests/67    # Bitbucket PR (v2.1.119+)
claude --from-pr https://ghe.example.com/org/repo/pull/89           # GitHub Enterprise (v2.1.119+)

Les sessions sont également associées automatiquement aux PR lorsque vous les créez avec gh pr create au cours d’une session. Vous pouvez ainsi reprendre facilement, par la suite, le travail sur une PR précise. Le badge de PR dans le pied de page peut pointer vers une URL personnalisée de revue de code grâce au paramètre prUrlTemplate (v2.1.119+) — utile lorsque votre équipe utilise, depuis les PR, des liens vers un outil de revue distinct.¹⁵²

/resume accepte les URL de PR (v2.1.122+). Coller une URL de PR dans le champ de recherche de /resume permet désormais de retrouver la session qui a créé cette PR à l’origine — cette fonctionnalité est compatible avec github.com, GitHub Enterprise, gitlab.com (ainsi que les instances GitLab auto-hébergées) et bitbucket.org.¹⁵⁴

Sessions nommées : Nommez les sessions au démarrage ou pendant leur déroulement :

# Name session at startup (v2.1.76+)
claude -n "auth-refactor"                  # --name flag sets display name[^125]

# Name current session
> /rename auth-refactor

# Resume by name or number
> /resume 1                    # Resume first session
> /resume auth-refactor        # Resume by name
claude --resume auth-refactor  # Resume from terminal
claude -r 3                    # Resume by number from terminal

# Fork for parallel exploration
claude --resume auth-refactor --fork-session

Remarque : --session-id exige un UUID valide (par exemple, 550e8400-e29b-41d4-a716-446655440000). Pour attribuer aux sessions des noms lisibles, utilisez plutôt /rename et --resume.

/fork crée une session en arrière-plan ; /subtask correspond à la duplication au sein de la session (v2.1.212). La commande /fork copie désormais la conversation actuelle dans une nouvelle session en arrière-plan — celle-ci dispose de sa propre ligne dans claude agents, ce qui vous permet d’envoyer la copie explorer une autre piste pendant que votre session principale se poursuit. L’ancien comportement — une duplication au sein de la session actuelle — subsiste sous le nouveau nom /subtask.¹⁸⁹ Depuis la v2.1.214, une session démarrée en tant que duplication indique la source "fork" au hook SessionStart (contre "resume" auparavant), ce qui permet aux hooks qui filtrent selon la source de les distinguer.¹⁹⁰ La v2.1.216 réduit la confirmation de /fork à une seule ligne indiquant le nom de la nouvelle session et son identifiant claude attach.¹⁹² Depuis la v2.1.221, une session dupliquée crée son propre worktree au lieu de travailler dans le checkout de la session d’origine — la copie qui explore une autre piste ne peut donc plus entrer en conflit avec les fichiers non validés de la session principale, ce qui constituait auparavant le principal risque lors de l’envoi d’une copie à des fins d’expérimentation.¹⁹⁹ La v2.1.232 fait aussi de la duplication le comportement par défaut des subagents : un subagent subagent_type: "fork" hérite de l’intégralité de la conversation et du cache de prompts, tandis que les agents créés hors d’une équipe dans les sessions interactives s’exécutent désormais en arrière-plan par défaut.²³²

Claude Code stocke les sessions sous forme de transcriptions JSONL. L’exécution des agents attribue des valeurs agentId uniques, avec des transcriptions stockées sous la forme agent-{agentId}.jsonl. La reprise conserve l’intégralité du contexte des conversations précédentes.

Mode plan

Le mode plan limite Claude à une exploration en lecture seule — aucune modification de fichier, aucune exécution Bash et aucune action destructive. Claude conçoit une stratégie d’implémentation, l’enregistre dans un fichier de plan, puis attend votre approbation avant toute exécution.

Activation du mode plan :

# Cycle through modes during a session
Shift+Tab           # Cycles: normal → plan → auto-accept

# Or use the /plan command with an optional description (v2.1.72+)
/plan                                     # Enter plan mode
/plan refactor the auth module            # Enter plan mode with a description

# Or ask Claude directly
"Plan how to refactor the auth module"   # Claude may enter plan mode automatically

Fonctionnement :

1. Claude passe en mode plan (automatiquement pour les tâches complexes ou avec Shift+Tab)
2. Explore la base de code à l’aide d’outils en lecture seule : Read, Glob, Grep, WebSearch, WebFetch
3. Enregistre un plan dans .claude/plans/{session-slug}.md
4. Quitte le mode plan avec ExitPlanMode et vous présente le plan pour examen
5. Vous approuvez le plan, demandez des modifications ou le rejetez

Outils disponibles en mode plan : Read, Glob, Grep, LS, WebSearch, WebFetch, AskUserQuestion. Les outils de modification (Edit, Write, Bash, NotebookEdit) sont bloqués.

Après l’approbation du plan (v2.1.32+) : Claude propose trois options : - « Oui, effacer le contexte et accepter automatiquement les modifications » (Shift+Tab) — repart avec un contexte vierge entièrement consacré au plan - « Oui, et approuver manuellement les modifications » — conserve le contexte ; vous approuvez chaque modification - « Oui, accepter automatiquement les modifications » — conserve le contexte ; Claude exécute le plan sans approbation pour chaque modification

L’effacement automatique du contexte après approbation constitue le workflow recommandé. Le plan bénéficie ainsi d’une nouvelle fenêtre de contexte, ce qui améliore considérablement son respect : Claude garde plus longtemps le cap sans subir l’interférence des échanges précédents.

Quand utiliser le mode plan : - Implémentation de nouvelles fonctionnalités nécessitant des décisions d’architecture - Refactorisations portant sur plusieurs fichiers lorsque vous souhaitez d’abord examiner l’approche - Bases de code inconnues, pour lesquelles l’exploration doit précéder les modifications - Toute tâche offrant plusieurs approches valables et pour laquelle vous souhaitez intervenir dans le choix

Conseil d’expert : Plus vous consacrez de temps au mode plan, plus Claude a de chances de réussir l’implémentation. Le mode plan permet une exploration pratiquement sans coût — aucun appel d’outil risqué, aucune modification inutile. Utilisez-le généreusement.

Mode lecteur d’écran (v2.1.208)

Claude Code intègre un mode lecteur d’écran dédié qui adapte l’interface du terminal aux technologies d’assistance. Vous pouvez l’activer de trois manières :¹⁸⁶

# Flag at launch
claude --ax-screen-reader

# Environment variable
export CLAUDE_AX_SCREEN_READER=1

# Or persistently in settings.json
{ "axScreenReader": true }

Anthropic décrit ce mode — ainsi que ses modes d’interaction — sur une nouvelle page consacrée à l’accessibilité dans la documentation officielle.¹⁸⁶

Présentation détaillée du système de configuration

Claude Code utilise un système de configuration à plusieurs niveaux. Il est essentiel d’en comprendre la hiérarchie, car les niveaux supérieurs remplacent les niveaux inférieurs, tandis que les paramètres d’entreprise ne peuvent en aucun cas être contournés.

Hiérarchie de configuration

Définir la configuration depuis le prompt : /config key=value (v2.1.181)

Depuis la v2.1.181, /config key=value permet de définir n’importe quel paramètre directement depuis le prompt — par exemple, /config thinking=false — sans ouvrir l’interface interactive de /config. Cette commande fonctionne dans les sessions interactives, -p et Remote Control. /config --help (v2.1.183) répertorie les clés abrégées disponibles. La v2.1.183 a également modifié l’interface interactive de /config : les touches Entrée et Espace activent ou désactivent désormais le paramètre sélectionné, tandis qu’Échap enregistre les modifications et ferme l’interface (auparavant, cette touche les annulait).¹⁷⁴

Référence complète de settings.json

Voici une configuration complète illustrant toutes les principales options :

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "model": "claude-sonnet-5",
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Bash(npm run:*)",
      "Bash(git:*)",
      "Bash(make:*)",
      "Edit(src/**)",
      "mcp__github"
    ],
    "deny": [
      "Read(.env*)",
      "Read(secrets/**)",
      "Bash(rm -rf:*)",
      "Bash(sudo:*)",
      "Edit(package-lock.json)",
      "Edit(.git/**)"
    ],
    "ask": [
      "WebFetch",
      "Bash(curl:*)",
      "Bash(docker:*)"
    ],
    "additionalDirectories": [
      "../shared-lib",
      "../docs"
    ],
    "defaultMode": "acceptEdits"
  },
  "env": {
    "NODE_ENV": "development",
    "DEBUG": "app:*"
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  },
  "sandbox": {
    "enabled": false,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["git", "docker"]
  },
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  },
  "includeCoAuthoredBy": true,
  "cleanupPeriodDays": 30,
  "outputStyle": "Explanatory",
  "language": "en",
  "respectGitignore": true,
  "showTurnDuration": true,
  "plansDirectory": ".claude/plans",
  "spinnerVerbs": ["Thinking", "Processing", "Analyzing"],
  "spinnerTipsOverride": {
    "label": "Team tips",
    "tips": [
      "Custom tip 1",
      {"id": "tip-2", "text": "Custom tip 2", "cooldownSessions": 5, "priority": 1}
    ],
    "tipsFile": "~/.claude/team-tips.json",
    "excludeDefault": true
  },
  "skillOverrides": {
    "legacy-skill": "off",
    "manual-only-skill": "user-invocable-only",
    "compact-skill": "name-only"
  },
  "includeGitInstructions": false,
  "modelOverrides": {
    "bedrock": "us.anthropic.claude-opus-5",
    "vertex": "claude-opus-5",
    "foundry": "claude-opus-4-8"
  },
  "autoMemoryDirectory": ".claude/memory",
  "sandbox": {
    "enableWeakerNetworkIsolation": true
  }
}

skillOverrides est utile lorsqu’une équipe dispose d’une vaste bibliothèque de skills, mais souhaite mieux contrôler leur disponibilité à l’exécution. Utilisez off pour masquer une skill à la fois au modèle et au sélecteur de commandes slash, user-invocable-only pour qu’elle reste invocable par son nom tout en étant exclue de la sélection par le modèle, et name-only pour rendre visible uniquement son nom, sans sa description complète.¹⁵⁶

Paramètres récents (v2.1.174–176) :

• availableModels / enforceAvailableModels (gérés, v2.1.175+) : la liste d’autorisation availableModels limite les modèles qu’une session peut sélectionner. Avec enforceAvailableModels: true, cette liste s’applique également au modèle Default : si Default correspond à un modèle non autorisé, le premier modèle autorisé est utilisé à la place. Les paramètres utilisateur ou de projet ne peuvent alors plus élargir une liste availableModels gérée. Un correctif associé (v2.1.176) comble la faille qui permettait à un alias de rediriger vers un modèle bloqué au moyen de ANTHROPIC_DEFAULT_*_MODEL. Désormais, /fast refuse également de basculer vers un modèle absent de la liste d’autorisation.¹⁷² Depuis la v2.1.187, les organisations peuvent imposer directement des restrictions de modèles dans le sélecteur /model, avec --model, /model et ANTHROPIC_MODEL : la sélection d’un modèle restreint affiche le message « restricted by your organization’s settings ».¹⁷⁶
• language (amélioration de la v2.1.176) : en plus de définir la langue des réponses, les titres de session sont désormais générés par défaut dans la langue de votre conversation ; définissez language pour imposer une langue particulière aux titres.¹⁷²
• footerLinksRegexes (v2.1.176) : badges de liens correspondant à des expressions régulières dans la ligne de pied de page, configurables depuis les paramètres utilisateur ou gérés.¹⁷²
• wheelScrollAccelerationEnabled (v2.1.174) : définissez cette option sur false pour désactiver l’accélération du défilement à la molette en mode plein écran.¹⁷²

Paramètres récents (v2.1.207–v2.1.212) :

• vimInsertModeRemaps (v2.1.208) : remappages de touches personnalisés pour le mode insertion de vim — l’exemple classique consiste à associer jj à Échap (consultez Mode Vim).¹⁸⁶
• axScreenReader (v2.1.208) : active durablement le mode lecteur d’écran (consultez Mode lecteur d’écran).¹⁸⁶
• processWrapper (v2.1.208) : fait passer chaque processus lancé par Claude Code pour son propre fonctionnement par un exécutable wrapper — conçu pour les lanceurs d’entreprise (consultez Lanceur d’entreprise).¹⁸⁶
• Restriction de la source de autoMode (v2.1.207) : le paramètre autoMode n’est plus lu depuis le fichier .claude/settings.local.json d’un dépôt — configurez-le plutôt dans ~/.claude/settings.json. Cela empêche un dépôt cloné d’embarquer une configuration du mode automatique.¹⁸⁵

Paramètres récents (v2.1.217) :

• emojiCompletionEnabled (v2.1.217) : autocomplétion des codes courts d’emoji dans la saisie du prompt — saisissez :heart: pour insérer ❤️, ou une forme partielle comme :hea pour obtenir des suggestions. Activée par défaut ; définissez cette option sur false pour la désactiver.¹⁹⁴

Paramètres récents (v2.1.219) :

• sandbox.network.strictAllowlist (v2.1.219) : refuse les hôtes absents de la liste d’autorisation pour les commandes exécutées dans la sandbox sans demander de confirmation, au lieu d’afficher une boîte de dialogue d’autorisation. Consultez Mode sandbox.¹⁹⁶
• workflowSizeGuideline (v2.1.219) : définit la recommandation indicative de taille des workflows Dynamic depuis n’importe quel fichier de paramètres — utilisateur, projet ou géré — et non plus uniquement via /config. Par défaut, les workflows Dynamic appliquent une recommandation medium (« aim for fewer than 15 agents ») ; la ligne correspondante dans /config se masque lorsqu’un fichier de paramètres fournit la valeur. Il s’agit d’une recommandation, pas d’une limite imposée. Consultez Subagents.¹⁹⁶

Paramètres récents (v2.1.242–243) :

• modelPicker (utilisateur ou géré, v2.1.242+) : personnalise le sélecteur /model avec une liste ordonnée et libellée de modèles. Il s’agit d’un objet contenant un tableau options (chaque ligne comporte un champ model obligatoire, ainsi que des champs label et description facultatifs ; model est repris tel quel, de sorte que les alias, les identifiants Anthropic et les identifiants Bedrock/Vertex/Foundry/gateway fonctionnent tous) et un booléen replaceBuiltInOptions facultatif (false, la valeur par défaut, ajoute les lignes après la sélection intégrée ; true affiche uniquement vos lignes, Default et le modèle déjà utilisé par la session). Claude Code lit cette clé depuis les paramètres gérés, --settings et les paramètres utilisateur, mais l’ignore dans les paramètres de projet et locaux. Ainsi, un dépôt cloné ne peut pas modifier les libellés du sélecteur ; la source de plus haute priorité qui la définit fournit l’ensemble de la liste. Une liste d’autorisation availableModels continue de s’appliquer à chaque ligne, et un libellé modifie ce que le sélecteur affiche, pas le modèle exécuté.²²⁷²²⁵
• promptCacheTtl / subagentPromptCacheTtl (tout fichier, v2.1.242+) : "5m" ou "1h" par catégorie de requêtes, afin que les utilisateurs d’une clé API et de fournisseurs cloud puissent conserver un cache d’une heure pour la conversation principale, tandis que les subagents restent à cinq minutes. Consultez Stratégies de mise en cache.²²⁷²²⁵
• modelPricing (géré, v2.1.243+) : tarifs négociés par modèle et multiplicateur de remise d’une organisation, utilisés par /cost, la ligne d’état et les données de coût de la télémétrie à la place du prix catalogue. Consultez Consulter les coûts.²²⁷

Paramètres récents (v2.1.247) : - feedbackDrafts (v2.1.247) : contrôle le nouvel outil SendFeedback – lorsqu’un problème survient au cours d’une session, Claude peut rédiger un rapport de retour d’expérience que vous pourrez relire et envoyer depuis /feedback ; désactivez cette rédaction avec ce paramètre. Consultez la ligne /feedback dans Commandes slash.²²² - Extension de la structure de spinnerTipsOverride (v2.1.247) : les astuces peuvent désormais être des objets {id, text, cooldownSessions, priority} en plus de simples chaînes de caractères, et l’objet accepte les clés tipsFile et label, afin que les organisations puissent afficher leurs propres astuces en alternance avec celles intégrées (l’exemple ci-dessus illustre cette structure étendue). La documentation des paramètres ne décrit pas encore les nouvelles clés – le CHANGELOG en est la seule source.²²²

Paramètres plus récents (v2.1.248–251) :

• desktopSessionCleanupPeriodDays (v2.1.248) : limite la durée pendant laquelle les sessions enregistrées par l’application de bureau échappent au nettoyage des transcriptions. Le correctif associé compte davantage que le paramètre lui-même : les sessions Claude Desktop et Cowork disparaissaient auparavant après cleanupPeriodDays (30 jours par défaut) ; le nettoyage les conserve désormais tant qu’elles figurent dans l’application, sauf si une politique de l’organisation gère leur conservation.²⁰⁶
• Restrictions de env au niveau du projet (v2.1.251) : un bloc env dans le fichier .claude/settings.json d’un projet ne peut plus définir CLAUDE_CONFIG_DIR, CLAUDE_CODE_TMPDIR ni TMPDIR/TMP/TEMP – définissez-les plutôt dans votre shell ou dans les paramètres utilisateur ou gérés, afin qu’un dépôt cloné ne puisse pas rediriger l’emplacement où Claude Code écrit ses fichiers de configuration et ses fichiers temporaires.²⁰⁶

Paramètres plus récents (v2.1.257-259) :

• timeFormat / timeZone (v2.1.257) : contrôlent la manière dont Claude Code affiche les heures – l’heure d’achèvement en fin de tour et les horodatages des transcriptions. timeFormat accepte un format sur 12 heures, sur 24 heures, sur 24 heures en UTC ou un motif strftime explicite ; timeZone indique le fuseau horaire. La documentation des paramètres ne les décrit pas encore – le CHANGELOG en est la source.²¹¹
• permissions.blockReadsOutsideWorkingDirectories (v2.1.257) : refuse catégoriquement la lecture des fichiers situés en dehors des dossiers de travail de la session. Sans ce paramètre, le mode automatique demande désormais une autorisation une seule fois, avant la première lecture de ce type au cours de la session (consultez Mode automatique).²¹¹ La v2.1.273 comble deux lacunes : une commande Bash que le vérificateur ne peut pas analyser entièrement déclenche une demande au lieu de contourner la vérification, et un dossier de mémoire sélectionné par les paramètres d’un dépôt n’est ni chargé, ni consulté, ni indexé lorsque ce paramètre est activé.²¹⁷
• managedMcpServers / managedSourcesBehavior : clés de portée gérée, abordées dans Déploiement en entreprise – pour les organisations qui fournissent des serveurs MCP à chaque utilisateur (v2.1.259) et pour la fusion facultative entre les sources gérées (affinée dans la v2.1.257).²¹¹²²¹

Paramètres plus récents (v2.1.261) :

• bashOutputMaxChars / taskOutputMaxChars (v2.1.261) : augmentent la quantité de sortie de commande (et, respectivement, de sortie de tâche en arrière-plan) que Claude reçoit directement avant que le reste ne soit enregistré dans un fichier, jusqu’à 128K caractères. Ce mécanisme diffère de la variable d’environnement BASH_MAX_OUTPUT_LENGTH, qui définit la fenêtre de relecture depuis le fichier de sortie de travail de la commande (30 000 caractères par défaut, avec un plafond de 150 000) : ces clés déterminent le seuil entre l’affichage direct et l’enregistrement dans un fichier persistant – au-delà, la sortie est placée dans un fichier que Claude peut lire à la demande au lieu d’être tronquée.²¹⁴ Depuis la v2.1.265, la partie persistante possède également une limite : les résultats d’outils enregistrés sur le disque sont plafonnés à 1 Go, et l’aperçu affiché dans la conversation signale lorsqu’un fichier enregistré a été tronqué.²¹⁵

Paramètres plus récents (v2.1.267-269) :

• maxEffortLevel (v2.1.267) : plafonne le niveau d’effort que les utilisateurs peuvent sélectionner – au niveau supérieur ou pour chaque modèle sous modelSettings – et s’applique à tous les fournisseurs, y compris Bedrock, Vertex et Foundry. Les utilisateurs peuvent toujours choisir un niveau inférieur au plafond ; il s’agit du pendant administratif de /effort.²¹⁶
• bashEditDiffEnabled (v2.1.269) : lorsque l’outil Bash modifie un fichier, son résultat contient un diff des fichiers modifiés par la commande, afin que la conversation montre ce qu’une modification de type sed a réellement changé.²¹⁶

Recherche de paramètres : les options les plus recherchées

Si vous êtes arrivé ici en recherchant un paramètre précis par son nom, voici l’index abrégé. Chaque entrée indique la version dans laquelle il a été introduit et, lorsqu’il relève d’une portée particulière, laquelle :

ANTHROPIC_API_KEY=sk-ant-...                    # Direct API authentication
ANTHROPIC_AUTH_TOKEN=token                      # Custom authorization header
ANTHROPIC_CUSTOM_HEADERS="X-Key: val"           # Additional request headers; credential/org/routing/API-behavior headers set from managed or project settings require approval (v2.1.251)[^238]

Configuration des modèles :

ANTHROPIC_MODEL=claude-opus-4-7                 # Override default model (Apr 16, 2026)
ANTHROPIC_DEFAULT_MODEL=claude-opus-5           # Model new sessions START on; a /model pick overrides + persists (v2.1.236)
ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5      # What the `opus` alias resolves to (Opus 5 since v2.1.219)
ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-4-6
ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5-20251001
CLAUDE_CODE_SUBAGENT_MODEL=sonnet               # Default model for subagents; an agent's model: field and per-spawn picks win (v2.1.251 demoted it from override to default)[^238]
CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1              # Force every subagent onto CLAUDE_CODE_SUBAGENT_MODEL (or the main model), ignoring agent-definition and per-spawn overrides -- the pre-v2.1.251 behavior, opt-in (v2.1.257)[^243]
CLAUDE_CODE_WORKFLOWS=1                         # Enable Workflow tool for deterministic multi-agent orchestration (v2.1.147+)
MAX_THINKING_TOKENS=10000                       # (Opus 4.6 and Sonnet 4.6 only — removed in Opus 4.7)
CLAUDE_CODE_MAX_OUTPUT_TOKENS=4000              # Limit output length
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1          # Enable agent teams (v2.1.32+)

Configuration du fournisseur cloud :

CLAUDE_CODE_USE_BEDROCK=1                       # Use AWS Bedrock
CLAUDE_CODE_USE_VERTEX=1                        # Use Google Vertex AI
CLAUDE_CODE_USE_FOUNDRY=1                       # Use Microsoft Foundry
ANTHROPIC_BEDROCK_BASE_URL=https://...          # Custom Bedrock endpoint
ANTHROPIC_BEDROCK_SERVICE_TIER=priority         # Bedrock service tier (v2.1.122+): 'default', 'flex', or 'priority'; sent as X-Amzn-Bedrock-Service-Tier header[^162]
CLAUDE_CODE_SKIP_BEDROCK_AUTH=1                 # Skip Bedrock auth (for gateways)
CLAUDE_CODE_SKIP_VERTEX_AUTH=1                  # Skip Vertex auth
AWS_BEARER_TOKEN_BEDROCK=token                  # Bedrock bearer token
VERTEX_REGION_CLAUDE_3_7_SONNET=us-west1        # Override Vertex region
CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1    # Opt in gateway /v1/models discovery for /model picker (v2.1.129+)[^164]
CLAUDE_CODE_GATEWAY_MODEL_DISCOVERY_TIMEOUT_MS=3000  # Extend the LLM gateway /v1/models discovery timeout (default 3s; v2.1.269+)[^252]
CLAUDE_CODE_GATEWAY_HINT_HEADERS=1              # Send five x-claude-code-* hint headers (request-class, agent-type, prev-tool-durations, compaction, context-compacted) for LLM gateways (opt-in; v2.1.273+)[^253]
CLAUDE_CODE_AUTO_MODE_SERVER=1                  # Use the platform's server-side auto-mode classifier on Bedrock/Vertex/Foundry; since v2.1.273 the local classifier is the default there "for now"[^253]

Contrôle du comportement :

DISABLE_AUTOUPDATER=1                           # Prevent automatic background updates
DISABLE_UPDATES=1                               # Block ALL update paths including manual `claude update` (v2.1.118+, stricter than DISABLE_AUTOUPDATER)[^160]
CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1       # Homebrew/WinGet installs run package-manager upgrade in background, then prompt restart (v2.1.129+)[^164]
DISABLE_TELEMETRY=1                             # Opt out of usage telemetry
DISABLE_ERROR_REPORTING=1                       # Disable Sentry
DISABLE_BUG_COMMAND=1                           # Disable /bug command
CLAUDE_CODE_RESTRICTED=1                        # Restricted mode: no command/code tools or WebFetch unless named in --tools; only managed settings load (v2.1.248+)[^238]
DISABLE_COST_WARNINGS=1                         # Hide cost warnings
DISABLE_PROMPT_CACHING=1                        # Disable prompt caching globally
DISABLE_PROMPT_CACHING_SONNET=1                 # Disable for Sonnet only
DISABLE_PROMPT_CACHING_OPUS=1                   # Disable for Opus only
DISABLE_NON_ESSENTIAL_MODEL_CALLS=1             # Skip non-critical API calls
ENABLE_PROMPT_CACHING_1H=1                      # Opt into 1-hour prompt cache TTL (v2.1.108+, API/Bedrock/Vertex/Foundry)
ENABLE_PROMPT_CACHING_1H_BEDROCK=1              # Deprecated alias for the above; v2.1.108+ still honors it on Bedrock but logs a deprecation notice
FORCE_PROMPT_CACHING_5M=1                       # Force 5-minute cache TTL (v2.1.108+)
CLAUDE_CODE_PROMPT_CACHE_TTL=1h                 # Main-conversation cache TTL, 5m or 1h; beats the promptCacheTtl setting (v2.1.242+)[^234]
CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL=5m        # TTL for subagents, workflows, forks, compaction, titles; beats subagentPromptCacheTtl (v2.1.242+)[^234]
ENABLE_TOOL_SEARCH=true                         # Re-enable tool search on Vertex AI (disabled by default v2.1.119+ to avoid unsupported beta header). Valid values: true, false, auto, auto:N[^160]
CLAUDE_CODE_HIDE_CWD=1                          # Hide the working directory in the startup logo (v2.1.119+)[^160]
CLAUDE_CODE_FORK_SUBAGENT=1                     # Enable forked subagents on external builds (v2.1.117+)[^160]
CLAUDE_CODE_FORCE_SYNC_OUTPUT=1                 # Force synchronized terminal output when auto-detection misses it, such as Emacs eat (v2.1.129+)[^164]
CLAUDE_CODE_SESSION_ID=...                      # Read-only: present in the Bash tool subprocess; matches the session_id passed to hooks (v2.1.132+)[^168]
CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1          # Skip the fullscreen alternate-screen renderer; keep the conversation in the terminal's native scrollback (v2.1.132+)[^168]
CLAUDE_EFFORT=...                               # Read-only: current effort level inside hooks and Bash tool subprocess (v2.1.133+)[^169]
CLAUDE_CODE_FORWARD_SUBAGENT_TEXT=1             # Include subagent text + thinking in stream-json output; pairs with --forward-subagent-text (v2.1.211+). Covers depth-2+ nested subagents as of v2.1.219[^205][^213]
CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=200    # Per-session WebSearch cap (default 200; v2.1.212+)[^206]
CLAUDE_CODE_WEBFETCH_CACHE_TTL_MS=900000        # WebFetch per-URL session cache TTL (default 15 min; v2.1.233+)[^226]
CLAUDE_CODE_WEBFETCH_DEADLINE_MS=300000         # WebFetch hard deadline: a server that never finishes its response fails the fetch after 300s by default; 0 disables (v2.1.268+)[^252]
CLAUDE_CODE_PROJECT_DIR_NAME=myproj             # Short name for the per-project transcript directory, for hosts that give each session its own config dir (v2.1.234+)[^227]
CLAUDE_CODE_GOAL_CHECKIN_MINUTES=30             # How long background tasks may keep a /goal waiting before Claude checks in on them; 0 disables (v2.1.234+)[^227]
CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=200       # Per-session subagent-spawn cap (default 200 in v2.1.212–223; the default cap was REMOVED in v2.1.224 — set this to reimpose one)[^206][^218]
CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=20         # Cap on concurrently-RUNNING subagents (default 20; distinct from the per-session total above; v2.1.217+)[^211]
CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS=0        # Disable the v2.1.229 workflow fan-out stagger (same-prefix sibling agents launch staggered so they read the cached prompt prefix instead of re-paying it)[^224]
CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS=64   # Raise the Workflow tool's per-run concurrent agent limit, 1-256, for inference-bound fan-outs (v2.1.269+)[^252]
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=3          # Nested subagent spawn depth. Default 3 as of v2.1.219; set 1 to disable nesting. Default history: 5 (v2.1.172–v2.1.216) → 1 (v2.1.217) → 3 (v2.1.219). Set it explicitly[^211][^213]

Configuration des outils :

BASH_DEFAULT_TIMEOUT_MS=30000                   # Bash command timeout (30s)
BASH_MAX_TIMEOUT_MS=600000                      # Maximum bash timeout (10min)
BASH_MAX_OUTPUT_LENGTH=50000                    # Read-back window from the Bash working output file (default 30,000 chars, hard ceiling 150,000)
CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR=1     # Reset CWD after each bash
MCP_TIMEOUT=5000                                # MCP server startup timeout
MCP_TOOL_TIMEOUT=30000                          # MCP tool execution timeout
MAX_MCP_OUTPUT_TOKENS=25000                     # MCP output limit
CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=120000       # Threshold before a long MCP tool call moves to the background (default 2 min; v2.1.212+)[^206]
CLAUDE_CODE_TOOL_MEMORY_LIMIT=4096              # Opt-in Linux memory cgroup (MB) for Bash tool commands — a runaway build can't stall the session (v2.1.233+)[^226]
CLAUDE_CODE_ENABLE_TODO_TOOLS=1                 # Offer the TodoWrite/TaskCreate-family tools on models outside v2.1.268's allowlist (Claude 3.x, Opus 4.0-4.7, Sonnet 4.0-4.6, Haiku 4.5); elsewhere they are off unless set (first turned off on newer models in v2.1.233)[^226][^252]
SLASH_COMMAND_TOOL_CHAR_BUDGET=15000            # Slash command context limit

Réseau et proxy :

HTTP_PROXY=http://proxy:8080                    # HTTP proxy
HTTPS_PROXY=https://proxy:8080                  # HTTPS proxy
NO_PROXY=localhost,example.com                  # Bypass proxy for domains
CLAUDE_CODE_CLIENT_CERT=/path/to/cert           # mTLS certificate
CLAUDE_CODE_CLIENT_KEY=/path/to/key             # mTLS private key
CLAUDE_CODE_CLIENT_KEY_PASSPHRASE=pass          # mTLS passphrase

Interface utilisateur et terminal :

CLAUDE_CODE_DISABLE_TERMINAL_TITLE=1            # Don't update terminal title
CLAUDE_CODE_IDE_SKIP_AUTO_INSTALL=1             # Skip IDE extension install
CLAUDE_CODE_SHELL=/bin/zsh                      # Override shell detection
USE_BUILTIN_RIPGREP=1                           # Use included ripgrep (default)
CLAUDE_CONFIG_DIR=~/.myconfig                   # Custom config directory; not settable from project-settings env (v2.1.251)[^238]
IS_DEMO=1                                       # Hide sensitive UI elements[^37]
CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1          # Disable background tasks and Ctrl+B[^46]
CLAUDE_CODE_TMPDIR=/path/to/tmp                 # Override temp directory; not settable from project-settings env, nor are TMPDIR/TMP/TEMP (v2.1.251)[^50][^238]
CLAUDE_CODE_DISABLE_1M_CONTEXT=1               # Hold ALL native-1M models to 200K via auto-compaction (v2.1.223 widened scope)[^103][^217]
CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1  # Let unrecognized model IDs exceed the assumed context window (v2.1.223)[^217]
CLAUDE_CODE_PLUGIN_GIT_TIMEOUT_MS=120000       # Plugin marketplace git timeout (default 120s, was 30s)[^105]
CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS=1        # Remove built-in commit/PR instructions[^117]
CLAUDE_CODE_DISABLE_CRON=1                    # Stop scheduled cron jobs mid-session[^121]
CLAUDE_CODE_SESSIONEND_HOOKS_TIMEOUT_MS=30000 # SessionEnd hooks timeout (default varies)[^123]
CLAUDE_CODE_USE_POWERSHELL_TOOL=1             # Enable Windows PowerShell tool on Linux/macOS (requires pwsh on PATH; v2.1.111+)[^153]
CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1           # Disable mouse click/drag/hover in fullscreen mode; wheel scroll still works (v2.1.195+)[^196]
CLAUDE_ENABLE_STREAM_WATCHDOG=0              # Disable the streaming idle watchdog (on by default for all providers since v2.1.196: aborts+retries after 5 min of silence)[^198]
CLAUDE_CODE_DISABLE_BG_SHELL_PRESSURE_REAP=1 # Turn off automatic memory-pressure reaping of idle background shell commands (v2.1.193+)[^196]
CLAUDE_CODE_ENABLE_AWAY_SUMMARY=1             # Force Session Recap when telemetry disabled (v2.1.108+)[^153]
CLAUDE_CODE_BG_TASKS_REPORT_RUNNING=0         # Restore pre-v2.1.269 behavior: remote/headless sessions may report "waiting for your input" while background agents still run[^252]
CLAUDE_AX_SCREEN_READER=1                     # Enable screen reader mode; same as --ax-screen-reader or "axScreenReader": true (v2.1.208+)[^203]
OTEL_LOG_RAW_API_BODIES=1                     # Emit full API request/response bodies as OTel log events (v2.1.111+)[^153]
TRACEPARENT=00-...                            # W3C Trace Context parent (v2.1.110+, SDK/headless)[^153]
TRACESTATE=vendor=value                       # W3C Trace Context state (v2.1.110+, SDK/headless)[^153]

Exportateurs OpenTelemetry et filtrage des champs sensibles :²⁴⁵

OTEL_LOGS_EXPORTER=none                       # OTel logs exporter (supports 'none' for disable; v2.1.85 fixed crash)
OTEL_METRICS_EXPORTER=none                    # OTel metrics exporter (supports 'none'; v2.1.85 fixed crash)
OTEL_TRACES_EXPORTER=none                     # OTel traces exporter (supports 'none'; v2.1.85 fixed crash)
OTEL_LOG_TOOL_CONTENT=1                       # Opt in to emitting tool content in OTel spans (v2.1.101+, sensitive by default)
OTEL_LOG_TOOL_DETAILS=1                       # Opt in to tool_parameters in OTel tool_result events (v2.1.85+); as of v2.1.273 also puts real agent, skill, plugin, and MCP server names on cost and token metrics[^253]
OTEL_LOG_USER_PROMPTS=1                       # Opt in to emitting user prompts in OTel traces (v2.1.101+, sensitive by default)
OTEL_LOG_ASSISTANT_RESPONSES=0                # Gate the claude_code.assistant_response log event holding the model's response text (v2.1.193+)
OTEL_METRICS_INCLUDE_REPOSITORY=1             # Tag OTel metrics and events with vcs.* repository attributes; with OTEL_LOG_TOOL_DETAILS, commit events carry vcs.ref.head.* (v2.1.269+)[^252]
CLAUDE_CODE_OTEL_CONTENT_MAX_LENGTH=60000     # Truncation limit for OTel content attributes (default 60 KB; v2.1.214+)[^207]
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1    # Disable release-notes fetch (v2.0.17+); v2.1.110 also stopped the auto-title Haiku request in headless/SDK when set

Attributs des spans de requête LLM dans la version 2.1.121 et les versions ultérieures : stop_reason, gen_ai.response.finish_reasons et user_system_prompt sont désormais émis sur les spans de requête LLM. user_system_prompt n’est activé que lorsque OTEL_LOG_USER_PROMPTS=1, car il peut contenir des données à caractère personnel.¹⁵⁴

Modifications au niveau des événements dans la version 2.1.122 et les versions ultérieures : les attributs numériques des événements de journalisation api_request et api_error sont désormais émis sous forme de nombres (auparavant, ils l’étaient sous forme de chaînes de caractères), ce qui corrige les collecteurs OTel en aval appliquant un typage strict au schéma. Le nouvel événement de journalisation claude_code.at_mention est déclenché lorsque Claude Code résout une mention @.¹⁵⁴

Événement de journalisation claude_code.assistant_response dans la version 2.1.193 et les versions ultérieures : Claude Code peut émettre le texte intégral de la réponse du modèle sous forme d’événement de journalisation OTel, sous réserve de l’activation de OTEL_LOG_ASSISTANT_RESPONSES. Ce mécanisme comporte un piège à connaître lors de la mise à niveau : lorsque OTEL_LOG_ASSISTANT_RESPONSES n’est pas défini, il suit OTEL_LOG_USER_PROMPTS. Par conséquent, tout déploiement qui journalise déjà le contenu des prompts commencera à recevoir le contenu des réponses de l’assistant après la mise à niveau. Définissez OTEL_LOG_ASSISTANT_RESPONSES=0 pour limiter la télémétrie aux prompts.¹⁷⁹

Ajouts de télémétrie dans la version 2.1.214 : les événements de journalisation OTel comportent désormais les attributs message.uuid, client_request_id et tool_source afin de corréler les données au niveau des messages et d’identifier la provenance des outils ; la charge utile subagentStatusLine inclut le niveau d’effort de raisonnement du subagent, ce qui permet aux lignes d’état personnalisées d’afficher conjointement le modèle et l’effort ; enfin, la nouvelle variable d’environnement CLAUDE_CODE_OTEL_CONTENT_MAX_LENGTH permet de configurer la limite de troncature de 60 Ko appliquée aux attributs de contenu OTel.¹⁹⁰

Télémétrie de la passerelle dans la version 2.1.265 : les sessions de passerelle des apps Claude exportent désormais les données OpenTelemetry directement vers un collecteur lorsque les paramètres gérés de la passerelle en désignent un dans OTEL_EXPORTER_OTLP_ENDPOINT, au lieu de passer par le relais de la passerelle ; les sessions pour lesquelles aucun collecteur n’est désigné continuent d’utiliser le relais. Cette même version ajoute user.email et user.groups aux données de télémétrie que Claude Desktop et Cowork envoient via une passerelle des apps Claude, comme le font déjà les sessions de terminal.²¹⁵

Contrôle de API / du modèle :²⁴⁵

CLAUDE_CODE_EXTRA_BODY='{...}'                # Inject extra body fields into API calls; v2.1.113 fixed 400 errors with output_config.effort on Vertex/subagent calls
CLAUDE_CODE_MAX_CONTEXT_TOKENS=200000         # Override max context tokens (pre-existing var; v2.1.98 fixed handling of DISABLE_COMPACT when both are set)
CLAUDE_CODE_FILE_READ_MAX_OUTPUT_TOKENS=25000 # Override default token limit for file read operations (v2.1.0+)
CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK=1   # Do not fall back to non-streaming API on streaming failures (v2.1.83+)
ANTHROPIC_BETAS=beta1,beta2                   # Enable beta API headers; v2.1.78 fixed silent ignore on Haiku models
ANTHROPIC_SMALL_FAST_MODEL=arn:...            # Fast model ID (Bedrock ARN supported; v0.2.125 stopped escaping slashes in ARN)

Plugins / MCP :²⁴⁵

CLAUDE_CODE_PLUGIN_CACHE_DIR=~/.claude/plugins # Plugin cache directory (v2.1.72 fixed literal '~' dir on some shells)
CLAUDE_CODE_PLUGIN_KEEP_MARKETPLACE_ON_FAILURE=1 # Preserve plugin marketplace cache when git pull fails (offline-friendly; v2.1.90+)
CLAUDE_CODE_MCP_SERVER_NAME=server1           # Passed to MCP headersHelper scripts so one helper can serve multiple servers (v2.1.85+)
CLAUDE_CODE_MCP_SERVER_URL=https://...        # Passed to MCP headersHelper scripts alongside the name (v2.1.85+)

Shell / IDE :²⁴⁵

CLAUDE_CODE_SHELL_PREFIX="time "              # Wrap every Claude-invoked shell command with a prefix (v1.0.61+)
CLAUDE_CODE_GIT_BASH_PATH=C:\Program\ Files\Git\bin\bash.exe  # Custom Git Bash path on Windows (v2.1.98+)
CLAUDE_CODE_EXIT_AFTER_STOP_DELAY=60000       # SDK: exit after N ms idle (v2.0.35+)
CLAUDE_CODE_AUTO_CONNECT_IDE=false            # Disable IDE auto-connection (v1.0.61+)

Entreprise / authentification :²⁴⁵

CLAUDE_CODE_PROXY_RESOLVES_HOSTS=1            # Opt into proxy-side DNS resolution (v2.0.55 moved this from default-on to opt-in)
CLAUDE_CODE_API_KEY_HELPER_TTL_MS=300000      # TTL for dynamically generated API keys via apiKeyHelper (apiKeyHelper refresh added v0.2.74 with 5-min default; env var added v0.2.117)
CLAUDE_CODE_PROCESS_WRAPPER=/path/to/wrapper  # Route all Claude Code self-spawned processes through a wrapper executable; same as the processWrapper setting (v2.1.208+)[^203]

Variables des skills (v2.1.69+) :

${CLAUDE_SKILL_DIR}                            # Self-reference for skills to locate their own directory[^117]

Identité de l’appelant SDK (v2.1.51+) :

CLAUDE_CODE_ACCOUNT_UUID=uuid                  # Provide account UUID synchronously for SDK callers
CLAUDE_CODE_USER_EMAIL=user@example.com        # Provide user email for SDK callers
CLAUDE_CODE_ORGANIZATION_UUID=uuid             # Provide organization UUID for SDK callers

Débogage :

ANTHROPIC_LOG=debug                             # Enable API request logging

Quel modèle choisir ?

Choisir le bon modèle pour chaque tâche a une incidence considérable sur le coût comme sur la qualité. Claude Code permet de changer facilement de modèle à plusieurs niveaux.

Modèles disponibles

Deux changements incompatibles lors de la migration d’un harness d’Opus 4.8 vers Opus 5 :¹⁹⁷

1. La réflexion est activée par défaut. Avec Opus 4.8, une requête dépourvue du champ thinking s’exécutait sans réflexion ; avec Opus 5, la même requête utilise la réflexion adaptative. max_tokens reste une limite stricte appliquée à l’ensemble de la sortie — réflexion et texte de la réponse — ; vérifiez donc à nouveau la marge disponible pour toute charge de travail qui s’exécutait auparavant sans réflexion. Transmettez thinking: {type: "disabled"} pour rétablir l’ancien comportement, sous réserve du point suivant.
2. Lorsque la réflexion est désactivée, l’effort est plafonné à high. L’association de thinking: {type: "disabled"} avec un effort xhigh ou max renvoie une erreur 400. La vérification s’effectue à chaque requête : augmenter l’effort à xhigh alors que la réflexion est désactivée entraîne un rejet, même si des tours précédents de la même conversation ont été acceptés.

Dans Claude Code en particulier : par défaut, effort est réglé sur high avec Opus 5 (comme avec le API Claude) et toute l’échelle est disponible — low, medium, high, xhigh, max. Les propres recommandations de migration de Anthropic préconisent de tester l’effort max lorsque les capacités comptent davantage que la consommation de tokens. Le mode rapide couvre Opus 5 au tarif de 10 $/50 $ par MTok (consultez Mode rapide).¹⁹⁷¹⁹⁸

Claude Fable 5.1 (1er septembre 2026) : Le nouveau sommet du niveau Fable et, depuis la v2.1.257, le modèle auquel correspond l’alias fable (sauf si ANTHROPIC_DEFAULT_FABLE_MODEL en épingle un autre) ; best signifie désormais « le dernier modèle Fable auquel vous avez accès ». La version minimale nécessite une explication : la documentation de configuration des modèles indique que l’alias a changé dans la v2.1.255 et la page du modèle précise que Fable 5.1 « nécessite Claude Code v2.1.255 ou version ultérieure », mais les versions 2.1.253 à 2.1.256 n’ont jamais été publiées sur npm – la v2.1.257 (1er septembre) est la première version installable qui l’intègre. ID du modèle : claude-fable-5-1 (Bedrock : anthropic.claude-fable-5-1). Même niveau et même tarif par token que Fable 5 – 10 $/MTok en entrée, 50 $/MTok en sortie, contexte de 1M, sortie maximale de 128K, réflexion adaptative toujours active, avec effort réglé par défaut sur high – avec une évolution tarifaire importante pour les longues sessions agentiques : les lectures du cache coûtent 0,25 $/MTok, soit 0,025 fois le prix d’entrée (2,5 %), contre 10 % habituellement ; seuls Fable 5.1 et Mythos 5.1 bénéficient de ce tarif, tandis que le prix des écritures dans le cache reste standard (12,50 $ pour 5 minutes, 20 $ pour 1 heure). Date limite des connaissances fiables : juin 2026 (les données d’entraînement s’arrêtent également en juin 2026) – la plus récente parmi tous les modèles Claude actuels. Retrait au plus tôt le 1er septembre 2027. Trois changements incompatibles par rapport à Fable 5 : l’utilisation forcée d’un outil renvoie une erreur, les modèles antérieurs ne peuvent pas lire ses blocs de réflexion et la modification de tours précédents invalide les blocs de réflexion. Cinq ajouts : effort par message (bêta), messages système limités à un tour (bêta), mises à jour de progression entre les appels d’outils (display: "updates", bêta), lectures du cache moins coûteuses et provenance du contenu. Claude Mythos 5.1 est le même modèle, avec les mêmes caractéristiques, accessible uniquement sur invitation via Project Glasswing. Avec ce lancement, Fable 5 rejoint le tableau des anciens modèles de la documentation, aux côtés d’Opus 4.8/4.7/4.6/4.5 et de Sonnet 4.6/4.5. Une réserve concernant la passerelle figure dans les notes de version : dans les sessions de passerelle des applications Claude, fable et best continuent pour le moment à correspondre à Fable 5 – une passerelle qui n’est pas encore configurée pour la version 5.1 la rejette – ; sélectionnez donc explicitement Fable 5.1 dans /model dans ce contexte. Notez qu’avant la v2.1.260, le sélecteur /model ne répertoriait pas Fable 5.1 : pour le choisir explicitement, il fallait donc saisir la commande complète /model claude-fable-5-1 (consultez les correctifs consécutifs au lancement ci-dessous). Les modèles par défaut des abonnements restent inchangés : Opus 5 avec les abonnements premium, Sonnet 5 avec Pro et Team Standard.^211218219

Correctifs consécutifs au lancement de Fable 5.1 (v2.1.260, 3 septembre) : la première version publiée après le lancement corrige quatre problèmes. Le sélecteur /model affiche désormais Fable 5.1 pour les organisations qui peuvent l’utiliser – avant ce correctif, le modèle n’était accepté que si son nom complet était saisi sous la forme /model claude-fable-5-1. Avec Fable 5.1, la mise en cache des prompts couvre maintenant le contexte joint après les résultats des outils, qui était auparavant renvoyé comme entrée non mise en cache à chaque tour comportant un appel d’outil – ce qui compromettait discrètement l’intérêt économique des lectures du cache à 0,025 fois le tarif standard, précisément pendant les longues sessions agentiques auxquelles elles sont destinées. Modifier /effort en cours de session n’invalide plus le cache des prompts. Enfin, les agents utilisant model: fable respectent désormais la balise [1m] d’une valeur épinglée avec ANTHROPIC_DEFAULT_FABLE_MODEL, au lieu de s’exécuter silencieusement avec une fenêtre de contexte de 200K.²¹²

Claude Fable 5 (9 juin 2026 ; ancien modèle depuis le 1er septembre 2026) : Un nouveau niveau de modèle supérieur à Opus — le modèle le plus puissant et le plus intelligent de Anthropic, à la pointe sur la quasi-totalité des benchmarks auxquels il a été soumis et conçu pour rester cohérent sur des millions de tokens de contexte. Fable 5 est le modèle de pointe « de classe Mythos » rendu sûr pour un usage général : il intègre des classificateurs de sécurité qui se rabattent sur Opus 4.8 pour les requêtes concernant la cybersécurité, la biologie-chimie et la distillation de modèles (Claude Mythos 5 est le même modèle sans ces mesures de protection, destiné aux chercheurs autorisés). Il est devenu sélectionnable dans Claude Code avec la v2.1.170 (9 juin 2026) — exécutez claude update, puis /model fable (l’alias court qui, depuis la v2.1.257, correspond à Fable 5.1 – pour sélectionner Fable 5 aujourd’hui, utilisez /model claude-fable-5) — et son déploiement dans les abonnements s’est poursuivi jusqu’au 22 juin 2026 (désormais terminé). ID du modèle : claude-fable-5. Fable 5 comprend par défaut une fenêtre de contexte de 1M ; le suffixe [1m] est donc inutile — et depuis la v2.1.173 (11 juin 2026), le nom de modèle claude-fable-5[1m] est automatiquement normalisé en claude-fable-5, avec suppression du suffixe (celui-ci n’a jamais eu de sens que pour Opus/Sonnet, où l’accès au contexte de 1M dépend de [1m]) ; sortie maximale de 128K. Le tarif s’élève à 10 $/MTok en entrée et à 50 $/MTok en sortie — environ deux fois celui d’Opus 4.8 — ; réservez-le donc aux raisonnements véritablement difficiles, et non aux modifications courantes. Il partage l’interface de requête d’Opus 4.8 (réflexion adaptative uniquement ; temperature/top_p/top_k et budget_tokens supprimés), avec une particularité supplémentaire : une valeur explicite thinking: {type: "disabled"} renvoie une erreur 400 ; omettez donc entièrement le paramètre thinking pour exécuter le modèle sans réflexion.²³⁸ Dans Claude Code en particulier : Fable 5 prend en charge toute l’échelle d’effort (low/medium/high/xhigh/max, high par défaut), tout comme Opus 5. La réflexion ne peut pas être désactivée sur Fable 5 — le bouton de réflexion de la session, le paramètre alwaysThinkingEnabled et MAX_THINKING_TOKENS=0 sont tous sans effet ; le modèle raisonne toujours de manière adaptative. Une surface de configuration complète propre à la famille fable reprend les réglages d’Opus : ANTHROPIC_DEFAULT_FABLE_MODEL fixe le modèle vers lequel pointe l’alias fable (utile sur Bedrock/Vertex/Foundry), DISABLE_PROMPT_CACHING_FABLE exclut Fable de la mise en cache des prompts, et le basculement automatique fondé sur le contenu s’applique aux passerelles d’entreprise. /model opus sélectionne désormais Opus 5 (effort élevé par défaut, /effort xhigh pour les tâches les plus difficiles), tandis que le modèle proposé par défaut dépend de votre forfait – Opus 5 avec les forfaits premium, Sonnet 5 avec Pro/Team Standard ; choisissez délibérément le niveau Fable avec /model fable lorsque vous recherchez les performances maximales – ce qui, depuis la v2.1.257, correspond à Fable 5.1.^238197207219

Opus 4.7 (16 avril 2026) : Le modèle phare de la génération précédente, toujours pleinement disponible. Fenêtre de contexte de 1M de tokens au tarif standard — sans supplément pour les contextes longs. Sortie maximale de 128K, réflexion adaptative uniquement (la réflexion étendue a été supprimée) et nouveau niveau d’effort xhigh, recommandé comme point de départ pour le développement et les charges de travail agentiques.¹⁴⁵ Date limite fiable des connaissances : janvier 2026. Date limite des données d’entraînement : janvier 2026. Identifiant du modèle : claude-opus-4-7. Les tarifs sont identiques à ceux d’Opus 4.6, à savoir 5 $/25 $ par MTok, avec 6,25 $ pour l’écriture en cache pendant 5 minutes, 10 $ pour l’écriture en cache pendant 1 heure et 0,50 $ par MTok pour la lecture du cache.¹⁴⁴ Opus 4.7 résout 3 fois plus de tâches de production sur SWE-Bench qu’Opus 4.6, obtient 70 % sur CursorBench (contre 58 % pour la version 4.6) et améliore de 13 % le taux de résolution sur le benchmark interne de développement de 93 tâches de Anthropic.¹⁴⁴ Il utilise un nouveau tokenizer — attendez-vous à des nombres de tokens environ 1 à 1,35 fois supérieurs pour un même texte ; augmentez la marge de max_tokens et les seuils de compactage.¹⁴⁵ La vision prend en charge les images jusqu’à 2 576 px / 3,75 MP, avec des coordonnées de pixels à l’échelle 1:1.¹⁴⁵

Benchmarks de développement d’Opus 4.7 (avril 2026) :¹⁵¹

Modèle par défaut selon le forfait (Claude Code) :²⁰⁷

Modifications incompatibles de Messages API dans Opus 4.7 (visibles par l’appelant) :¹⁴⁵

• Le paramètre budget_tokens de la réflexion étendue a été supprimé. Utilisez plutôt thinking: {type: "adaptive"}. La réflexion adaptative est désactivée par défaut ; les requêtes dépourvues de champ thinking s’exécutent sans réflexion.
• Définir temperature, top_p ou top_k sur une valeur autre que celle par défaut renvoie une erreur HTTP 400. Omettez ces paramètres et orientez le modèle au moyen du prompt.
• Le contenu de la réflexion est omis des réponses par défaut. Définissez thinking.display: "summarized" pour rétablir un raisonnement visible (indispensable si votre produit diffuse la réflexion aux utilisateurs).

Les budgets de tâche (en-tête bêta task-budgets-2026-03-13) vous permettent d’indiquer au modèle un objectif de tokens pour l’ensemble d’une boucle agentique via output_config.task_budget ; minimum de 20K tokens.¹⁴⁵

Opus 4.6 (ancien modèle) : Toujours disponible sous claude-opus-4-6, avec un contexte de 1M et une sortie maximale de 128K. Envisagez de migrer vers Opus 4.7 pour bénéficier de meilleures performances en développement agentique. Opus 4.6 est initialement sorti le 5 février 2026.⁷⁹¹⁴⁴ Depuis la v2.1.117 (22 avril 2026), les abonnés Pro et Max utilisent par défaut l’effort high avec Opus 4.6 et Sonnet 4.6 (contre medium auparavant) ; Opus 4.7 reste réglé sur xhigh. Ce changement a rétabli le niveau d’intelligence après la baisse d’effort appliquée du 4 mars au 7 avril et documentée dans l’analyse rétrospective du 23 avril.¹⁵²¹⁵³

Sonnet 5 (30 juin 2026) : Le niveau Sonnet actuel, présenté comme « la meilleure combinaison de vitesse et d’intelligence ». Selon Anthropic, ses performances sont proches de celles d’Opus 4.8, mais à moindre coût. Il améliore considérablement Sonnet 4.6 en matière de raisonnement agentique, d’utilisation d’outils, de développement et de travail intellectuel — tout en présentant globalement moins de comportements indésirables et des capacités de cybersécurité bien inférieures à celles des modèles Opus (le compromis de sécurité qui a permis son lancement sans restrictions à l’exportation). Identifiant du modèle : claude-sonnet-5 (instantané fixe sans date). Fenêtre de contexte de 1M de tokens, sortie maximale de 128K (jusqu’à 300K avec API Batches et l’en-tête bêta output-300k-2026-03-24), réflexion adaptative uniquement. Date limite fiable des connaissances : janvier 2026. Tarifs : 2 $/10 $ par MTok en entrée/sortie, désormais le tarif catalogue standard. Lors du lancement, Anthropic avait annoncé ces tarifs de 2 $/10 $ comme offre de lancement valable jusqu’au 31 août 2026, avant de les pérenniser : la page des tarifs précise que l’augmentation à 3 $/15 $ prévue le 1er septembre « n’aura pas lieu », tandis que la v2.1.243 a mis à jour le sélecteur /model et la skill claude-api incluse pour présenter 2 $/10 $ comme tarif catalogue plutôt que comme promotion temporaire.²²⁸ Ce tarif est inférieur de 60 % aux 5 $/25 $ d’Opus 5. Dans Claude Code, le paramètre effort vaut high par défaut avec Sonnet 5 (définissez-le explicitement pour le modifier). Sélectionnez-le avec /model sonnet (ou /model claude-sonnet-5).¹⁸⁰ La v2.1.197 (30 juin 2026) a fait de Sonnet 5 le modèle par défaut de Claude Code pour les nouvelles sessions à cette époque ; aujourd’hui, il reste le modèle par défaut du niveau standard (Pro, Team Standard), tandis que les forfaits premium et Anthropic API utilisent Opus 5 par défaut – consultez le tableau des forfaits ci-dessus.¹⁸¹²⁰⁷

Sonnet 4.6 (17 février 2026, désormais remplacé par Sonnet 5) : Modèle équilibré ; il a remplacé Sonnet 4.5 comme modèle par défaut sur claude.ai et dans Claude Cowork.⁹³ Même tarification que Sonnet 4.5 (3 $/15 $ par MTok). Performances améliorées pour la recherche agentique, avec une consommation moindre de tokens. Prend en charge la réflexion étendue, la réflexion adaptative et une fenêtre de contexte de 1M de tokens (bêta). Sortie maximale de 64K (limite supérieure de 128K dans la v2.1.77).¹¹⁹ Date limite des connaissances : août 2025 (fiable), janvier 2026 (données d’entraînement). Identifiant du modèle : claude-sonnet-4-6.

Claude Mythos Preview (7 avril 2026) : Modèle de pointe en préversion de recherche pour les travaux de cybersécurité défensive, proposé dans le cadre de Project Glasswing.¹³⁹ Sur invitation uniquement ; non disponible au grand public. Anthropic présente Opus 4.7 comme délibérément moins performant que Mythos dans le domaine de la cybersécurité — un compromis dicté par la sûreté — et a ouvert un Cyber Verification Program à l’adresse https://claude.com/form/cyber-use-case pour les chercheurs en sécurité légitimes ayant besoin d’un accès étendu.¹⁴⁶

Pourquoi ces différences de prix sont importantes : Une session de développement classique consomme entre 50K et 200K tokens d’entrée et entre 10K et 50K tokens de sortie. Avec Haiku, cela représente entre 0,10 $ et 0,45 $ par session. Avec Opus, la même session coûte entre 0,50 $ et 2,25 $, soit 5 fois plus. Réservez Opus aux problèmes réellement difficiles.¹

Quand utiliser chaque modèle

Haiku : utilisez-le pour les subagents chargés de l’exploration, les recherches simples dans les fichiers et les questions rapides. Il est environ 5 fois moins cher qu’Opus et répond plus rapidement. Il convient parfaitement aux tâches d’arrière-plan qui ne nécessitent pas de raisonnement approfondi. Sonnet : le modèle polyvalent pour le développement quotidien lorsque le coût compte — et le modèle par défaut avec l’offre standard, Pro et Team Standard (contexte natif de 1M, tarif standard de 2 $/10 $ par MTok ; l’augmentation prévue le 1er septembre a été annulée).^181228207 Il gère la plupart des tâches de programmation : implémentation de fonctionnalités, correction de bugs, écriture de tests et revue de code. Historique : la v2.1.197 (30 juin 2026) a longtemps été présentée — y compris ici — comme faisant de Sonnet 5 le modèle par défaut partout, mais la documentation de configuration des modèles indique que, selon l’offre, le modèle par défaut avec premium/API correspond à Opus 4.8 depuis la v2.1.154 et à Opus 5 depuis la v2.1.219 ; « partout » désignait donc en réalité l’offre standard. Sonnet 4.6 a conservé le rôle de Sonnet jusqu’en juin 2026.^93147207 Utilisez Sonnet lorsque vous avez besoin de tokens moins chers, d’une latence plus faible ou d’un meilleur rapport coût-efficacité pour les subagents.

Opus : le modèle dédié au raisonnement approfondi — depuis la v2.1.219, l’alias opus sélectionne Claude Opus 5 (5 $/25 $ par MTok, contexte de 1M, avec effort défini par défaut sur high).¹⁹⁷ Le paragraphe ci-dessous décrit Opus 4.7 lors de son lancement le 16 avril 2026 et est conservé à titre historique.¹⁴⁴¹⁴⁷ Réservez ce raisonnement plus coûteux aux situations où il est vraiment rentable : décisions d’architecture, débogage complexe, compréhension de systèmes complexes, analyse de sécurité et travaux agentiques de longue haleine. Opus 4.7 résout 3 fois plus de tâches de production sur SWE-Bench qu’Opus 4.6, obtient un score de 70 % sur CursorBench (contre 58 %) et améliore de 13 % le taux de résolution sur un benchmark interne de programmation comprenant 93 tâches.¹⁴⁴ Claude Code utilise par défaut un effort xhigh avec Opus 4.7, réglable via /effort (v2.1.111+).¹⁴⁶¹⁴⁷ Auto Mode est disponible pour les abonnés Max utilisant Opus 4.7 via Anthropic API, sans nécessiter --enable-auto-mode ; pour les autres offres et fournisseurs, sa disponibilité dépend de l’offre et des paramètres définis par l’administrateur.¹⁴⁶ Contexte de 1M au tarif standard — sans supplément pour les longs contextes. Changements de comportement à connaître : Opus 4.7 suit les instructions plus littéralement, adapte la longueur de ses réponses à la complexité de la tâche, exécute moins de subagents par défaut et adopte un ton plus direct, avec moins de formulations axées sur la validation. Si vos prompts contiennent des instructions destinées à imposer des messages de progression intermédiaires ou une double vérification, essayez de les supprimer.¹⁴⁵

Opusplan : un mode hybride qui utilise Opus pour la planification, où la qualité du raisonnement compte le plus, et Sonnet pour l’exécution, où la vitesse prime. Excellent pour les refactorisations complexes lorsque vous souhaitez bénéficier du meilleur plan sans avoir besoin du niveau de raisonnement d’Opus pour chaque modification.

Changer de modèle

Pendant une session :

> /model opus
> /model sonnet
> /model haiku

Au démarrage :

claude --model opus

Via l’environnement :

export ANTHROPIC_MODEL=opus

Dans settings.json :

{
  "model": "claude-sonnet-5"
}

Personnaliser le sélecteur lui-même (modelPicker, v2.1.242+) : un fichier de paramètres utilisateur ou gérés peut répertorier les modèles proposés par /model, dans l’ordre et sous les libellés de votre choix, au lieu de limiter le menu aux options intégrées. Chaque ligne indique un model (toute valeur acceptée par --model, y compris les identifiants Vertex et Bedrock), ainsi qu’un label et une description facultatifs ; définissez replaceBuiltInOptions sur true pour n’afficher que ces lignes, en plus de Par défaut et du modèle utilisé par la session. Les paramètres du projet et les paramètres locaux sont ignorés pour cette clé, tandis qu’une liste d’autorisation availableModels continue de filtrer les lignes. Claude Code supprime toute ligne qu’il ne peut pas prendre en charge, grise toute ligne que vous ne pouvez pas encore sélectionner en indiquant la raison et revient à la liste intégrée si aucune ligne n’est retenue.²²⁷²²⁵

{
  "modelPicker": {
    "options": [
      { "model": "us.anthropic.claude-opus-4-8", "label": "Opus (production)" },
      {
        "model": "us.anthropic.claude-sonnet-4-6",
        "label": "Sonnet (production)",
        "description": "Day-to-day work"
      }
    ]
  }
}

Spécifiquement pour les subagents :

export CLAUDE_CODE_SUBAGENT_MODEL=haiku

Depuis la v2.1.251, CLAUDE_CODE_SUBAGENT_MODEL définit le modèle par défaut des subagents au lieu de tout remplacer : le champ model: d’une définition d’agent et un modèle explicitement choisi pour une création donnée sont prioritaires.²⁰⁶ Depuis la v2.1.257, CLAUDE_CODE_SUBAGENT_MODEL_FORCE permet de rétablir l’ancien comportement en option : il applique CLAUDE_CODE_SUBAGENT_MODEL (ou le modèle de la conversation principale si cette variable n’est pas définie) à chaque subagent, sans tenir compte des choix effectués lors de leur création ni du champ model: des définitions d’agents.²¹¹

Chaîne de modèles de secours (v2.1.166+) : le paramètre fallbackModel permet de configurer jusqu’à trois modèles de secours, essayés dans l’ordre lorsque le modèle principal est surchargé ou indisponible. L’option --fallback-model (auparavant limitée aux changements en cours de session) s’applique désormais aussi aux sessions interactives dès leur démarrage.²⁴⁰

{
  "model": "claude-opus-4-8",
  "fallbackModel": ["claude-sonnet-4-6", "claude-haiku-4-5"]
}

Lorsque API renvoie une erreur inattendue qui ne peut pas faire l’objet d’une nouvelle tentative, Claude Code réessaie désormais aussi une fois l’échange avec le modèle de secours avant de signaler l’échec. Ainsi, un problème transitoire du modèle principal entraîne une dégradation progressive au lieu d’interrompre l’échange.²⁴⁰

Depuis la v2.1.178, la compaction respecte elle aussi la chaîne de secours — si le modèle principal est surchargé ou indisponible pendant une compaction, cette étape utilise la chaîne fallbackModel/--fallback-model configurée au lieu de faire échouer l’échange. Lors d’une longue exécution autonome, cela comble la lacune qui permettait à une compaction normalement récupérable d’interrompre la session en cas d’erreur transitoire du modèle.¹⁷³

Contexte étendu

Pour les grandes bases de code ou les longues sessions, activez un contexte de 1M tokens :

claude --model sonnet[1m]
claude --model opus[1m]           # Opus 4.7 with 1M context

Ou au cours d’une session :

> /model sonnet[1m]
> /model opus[1m]

Opus 4.7, Opus 4.6 et Sonnet 4.6 incluent tous la fenêtre contextuelle complète de 1M tokens au tarif standard — sans supplément pour les longs contextes.¹⁴⁸ Une requête de 900K tokens est facturée au même tarif par token qu’une requête de 9K tokens. Les réductions liées à la mise en cache des prompts et au traitement par lots s’appliquent aux tarifs standard sur l’ensemble de la fenêtre contextuelle.

Avec les abonnements Max, Team et Enterprise, Opus avec un contexte de 1M est inclus automatiquement — aucun suffixe [1m] n’est nécessaire (activé par défaut depuis la v2.1.75, le 13 mars 2026).¹¹⁷¹⁴⁷ Avec Pro, le contexte de 1M est accessible via l’utilisation supplémentaire. Les utilisateurs de API et ceux qui paient à l’usage disposent d’un accès complet à 1M au tarif standard par token.¹⁴⁷

Pour désactiver les variantes avec contexte de 1M dans le sélecteur de modèles, définissez CLAUDE_CODE_DISABLE_1M_CONTEXT=1. Depuis la v2.1.223, la portée de cette variable a changé : elle limite à 200K, par compaction automatique, tous les modèles dotés nativement d’une fenêtre de 1M — et non plus seulement une liste fixe de variantes connues — et un avertissement s’affiche au démarrage lorsque la compaction automatique ne limite pas réellement la session à 200K. Si vous utilisez cette variable pour garantir la prévisibilité des coûts avec une famille de modèles, elle s’applique désormais aux nouveaux modèles de 1M dès leur sortie au lieu de cesser silencieusement de faire effet. Cette même version permet à la compaction automatique de maintenir les sessions utilisant des identifiants de modèle non reconnus dans les limites de la fenêtre contextuelle présumée, au lieu de les laisser la dépasser ; CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1 rétablit l’ancien comportement pour les passerelles qui enregistrent des identifiants personnalisés avec des fenêtres réelles plus grandes.²⁰⁰

Depuis la v2.1.247, la fenêtre de compaction automatique par défaut de Sonnet 5 correspond à son contexte complet de 1M : les sessions utilisant la fenêtre de 1M sont désormais compactées automatiquement vers 967K tokens au lieu d’environ 934K.²²² La v2.1.260 étend cette compaction automatique à l’approche de la limite au reste des modèles de 1M : les sessions Opus et Fable sont désormais elles aussi compactées peu avant la limite de 1M tokens, et la compaction de récupération sur les contextes très volumineux n’expire plus au bout de 10 minutes.²¹²

Depuis la v2.1.271, --resume conserve la fenêtre [1m] : la reprise d’une session dont la famille de modèles diffère du modèle configuré par défaut ne supprime plus le suffixe [1m].²¹⁶

La v2.1.273 corrige le compteur de contexte et la compaction automatique, qui comptabilisaient les échanges de l’outil advisor à environ deux fois leur taille contextuelle réelle — la compaction automatique se déclenchait à environ la moitié de la fenêtre réelle.²¹⁷

Vérifier le modèle actuel

> /status

Cette commande affiche le modèle actuel, les informations du compte, les paramètres appliqués et d’autres données sur l’état de la session.

Libellés du sélecteur de modèles (v2.1.51+) : le sélecteur /model affiche désormais des libellés lisibles (par exemple, « Sonnet 4.6 ») au lieu des identifiants bruts des versions épinglées, ainsi que des suggestions de mise à niveau lorsque des versions plus récentes sont disponibles.⁹⁸ La v2.1.219 corrige l’affichage de la ligne Opus fusionnée pour qu’elle apparaisse simplement sous la forme « Opus » au lieu de « Opus (contexte de 1M) », et limite la mise en évidence d’une nouvelle version au seul nom du modèle le plus récent, afin qu’elle signale ce qui vient réellement de sortir plutôt qu’une portion arbitraire de la liste.¹⁹⁶

Fast Mode (v2.1.36+)

Fast Mode fournit une sortie nettement plus rapide à partir du même modèle ; il ne bascule pas vers un modèle moins cher. Activez-le ou désactivez-le pendant une session avec /fast.⁸⁶

> /fast            # Toggle fast mode on/off

Modèles concernés (à compter de la v2.1.219) : le mode rapide s’applique à Claude Opus 5 et Claude Opus 4.8. La v2.1.219 a retiré Opus 4.7 du mode rapide, et cette fonctionnalité n’a jamais été disponible sur Sonnet, Haiku ou Fable. Elle reste en version préliminaire de recherche uniquement sur Claude API (y compris Claude Managed Agents), et non sur Amazon Bedrock, Google Cloud, Microsoft Foundry ou Claude Platform on AWS. L’accès est restreint : contactez votre responsable de compte ou inscrivez-vous sur la liste d’attente.¹⁹⁶¹⁹⁸

Sessions distantes (v2.1.271) : le mode rapide est désormais disponible dans les sessions Claude Code Remote, qu’il s’agisse de sessions cloud ou de runners auto-hébergés. Le paramètre de mode rapide de l’hôte s’applique, mais vous pouvez aussi saisir /fast dans la session elle-même ; les deux méthodes ne fonctionnent que si votre organisation autorise le mode rapide. Cette même version corrige /fast off : la commande désactive désormais le mode rapide au lieu de répondre « Fast mode unavailable » lorsque celui-ci est désactivé au niveau de l’organisation.²¹⁶

Tarification (mode rapide d’Opus 5 / Opus 4.8) :¹⁹⁸

Le piège d’Opus 4.7 (v2.1.219). Les modèles non pris en charge ne se comportent pas tous de la même manière. Une requête adressée à claude-opus-4-7 avec speed: "fast" renvoie désormais une erreur : elle ne revient pas silencieusement à la vitesse standard. Opus 4.6 constitue l’exception qui rend cette distinction utile à connaître : il accepte speed: "fast", mais s’exécute tout de même à la vitesse standard, est facturé aux tarifs standard et indique usage.speed: "standard". Si votre harness était épinglé à la version 4.7 et comptait sur une rétrogradation silencieuse des requêtes en mode rapide, celles-ci échouent désormais purement et simplement ; migrez l’épinglage vers Opus 5 ou 4.8.¹⁹⁸

Quand utiliser le mode rapide : - Pour itérer rapidement sur de petites modifications lorsque la latence constitue le principal frein - Pour générer des tests, du code standard ou du code répétitif lorsque la vitesse compte davantage que le coût - Pour traiter séquentiellement une liste de tâches similaires

Quand NE PAS utiliser le mode rapide : - Pour les tâches agentiques de longue durée (le coût reste doublé sur l’ensemble de l’exécution) - Pour le travail des subagents en arrière-plan (personne n’attend le résultat) - Pour les sessions soumises à des contraintes budgétaires

Le mode rapide inclut la fenêtre de contexte complète de 1M (v2.1.50+). La tarification applique un multiplicateur fixe à l’ensemble du contexte, y compris aux requêtes dépassant 200K tokens d’entrée, sans supplément pour contexte long ; ce multiplicateur se cumule avec ceux liés à la mise en cache des prompts et à la résidence des données.⁹⁶¹⁹⁸

Notes opérationnelles. Le mode rapide dispose de sa propre limite de débit, distincte des limites d’Opus standard ; son dépassement renvoie une erreur 429 accompagnée de retry-after (les en-têtes de réponse anthropic-fast-*-tokens-* indiquent la capacité restante). Basculer entre les modes rapide et standard invalide le cache des prompts : les requêtes exécutées à des vitesses différentes ne partagent pas les préfixes mis en cache. Activer ou désactiver /fast au milieu d’une session entraîne donc un défaut de cache. Le mode rapide n’est pas disponible avec le Batch API ni avec un engagement Priority Tier.¹⁹⁸

Conseil d’expert : le mode rapide ne se combine pas avec opusplan (opusplan associe déjà Opus et Sonnet ; le mode rapide n’agit que sur la partie Opus). Utilisez-le lorsque la latence compte davantage que le coût, et désactivez-le pour les tâches autonomes ou par lots. /fast nécessite de l’utilisation supplémentaire ; les administrateurs Team/Enterprise peuvent devoir l’activer au préalable (correctif de la v2.1.37). Désactivez-le complètement avec CLAUDE_CODE_DISABLE_FAST_MODE=1. Depuis la v2.1.218, Claude Code vous avertit lorsqu’un changement de modèle via /config model=<x> ou Remote Control modifie l’état du mode rapide. La v2.1.219 a également corrigé le maintien d’un état obsolète du mode rapide dans les clients Remote Control après un changement de modèle, une reconnexion ou l’échec d’une vérification de l’organisation.^86149195196

Contrôle de l’effort (v2.1.111+, Opus 4.7)

Opus 4.7 introduit un nouveau réglage de l’effort qui ajuste le compromis entre vitesse et intelligence. Utilisez /effort pendant une session :

> /effort              # opens an interactive slider (arrow keys + Enter)
> /effort xhigh        # set directly

Enregistrement par modèle (v2.1.251+) : /effort enregistre désormais votre niveau d’effort par défaut pour chaque modèle. Chacun conserve donc son propre réglage lorsque vous changez de modèle : votre habitude d’utiliser xhigh sur Opus ne vous suit plus sur Haiku (CHANGELOG : « Modification de /effort afin d’enregistrer votre niveau d’effort par défaut pour chaque modèle ; chacun conserve ainsi son propre réglage lorsque vous changez de modèle »). L’exception limitant max à la session reste applicable.²⁰⁶ La v2.1.257 affine les deux réglages : /effort accepte s pour un choix limité à la session, conformément à la convention de /model, et le flag --effort est désormais limité à la session : il lève le maintien du niveau d’effort par défaut d’un nouveau modèle pour cette seule session, sans effet permanent (selon la référence CLI, il « remplace » la valeur par défaut « pour cette session et ne persiste pas »).²¹¹²²⁰

Mode Auto sur Max (v2.1.111+)

Depuis le 14 août 2026, le mode Auto est le mode d’autorisation par défaut des forfaits Pro, Max et Team (annonce du 7 août) — consultez Modes d’autorisation pour connaître les chiffres de l’étude citée dans l’annonce, les méthodes de désactivation ainsi que les forfaits et passerelles pour lesquels une activation explicite reste nécessaire.²⁰³ À l’origine, il constituait une alternative plus sûre à --dangerously-skip-permissions, proposée d’abord aux abonnés Max utilisant Opus 4.7 via Anthropic API.¹⁴⁶ Un modèle de classification distinct — Claude Sonnet 5 depuis la v2.1.210 — examine chaque action avant son exécution afin de vérifier qu’elle correspond à l’intention et qu’elle est sûre.¹⁸⁷ Remarque (v2.1.111+) : le flag --enable-auto-mode a été supprimé ; pour démarrer une session en mode Auto, utilisez désormais --permission-mode auto. Pro est resté exclu du mode Auto pendant la majeure partie de l’existence de celui-ci, restriction à laquelle met fin son déploiement par défaut du 14 août. Bedrock/Vertex/Foundry (v2.1.158+) : sur ces passerelles, le mode Auto est devenu disponible sur activation explicite avec Opus 4.7 et Opus 4.8, au moyen de CLAUDE_CODE_ENABLE_AUTO_MODE=1.²⁴³ Depuis la v2.1.207, cette activation explicite n’est plus nécessaire : le mode Auto fonctionne sur AWS Bedrock, Google Vertex AI et Microsoft Foundry sans CLAUDE_CODE_ENABLE_AUTO_MODE. Les administrateurs souhaitant le désactiver doivent utiliser le paramètre géré disableAutoMode. Cette même version définit également Claude Opus 4.8 comme modèle par défaut sur Bedrock, Vertex AI et Claude Platform on AWS, et cesse de lire le paramètre autoMode dans le fichier .claude/settings.local.json d’un dépôt : configurez plutôt les règles du mode Auto dans ~/.claude/settings.json.¹⁸⁵ Depuis la v2.1.247, les invites d’autorisation de Bash affichent un conseil renvoyant vers le mode Auto, avec une option activable d’une seule touche : « Oui, et passer en mode Auto ».²²² Depuis la v2.1.273, le mode Auto sur Bedrock, Vertex AI et Foundry utilise par défaut le classificateur local « pour le moment » ; définissez CLAUDE_CODE_AUTO_MODE_SERVER=1 pour employer le classificateur côté serveur de la plateforme. Il s’agit d’un changement d’état sur un axe distinct de la note de la v2.1.236 relative aux valeurs par défaut du classificateur : le choix entre traitement local et côté serveur est un mécanisme que les versions antérieures n’avaient jamais exposé.²¹⁷ Ce que le mode Auto n’est pas : une barrière de sécurité. L’essentiel de ce qui suit renforce un classificateur, et un classificateur n’est pas une sandbox. Le 26 août 2026, Johann Rehberger, chercheur spécialisé dans les prompt injections, a publié une chaîne d’attaque fonctionnelle contre Claude Code Opus 5 en mode Auto, faisant état d’un taux de réussite de 60 à 80 % sur de petits échantillons : 3 exécutions sur 5 pour la chaîne principale, qui lance un processus enfant python3 isolé, ainsi que 3 sur 5 et 4 sur 5 pour deux configurations d’une variante dont la charge utile lance une instance claude -p headless. Il précise lui-même qu’il s’agit de petits échantillons, et non d’une mesure universelle du taux de réussite de l’attaque.²¹⁰ Cette chaîne mérite d’être comprise, car chaque étape prise séparément paraît raisonnable : un serveur répond à WebFetch avec un code HTTP 415, si bien que l’agent se rabat sur curl ; l’archive téléchargée est extraite dans un dossier de travail contenant un manifeste, sept enregistrements de données encodés en Base85/zlib, un binaire natif et un fichier struct.py ; Claude refuse d’exécuter le binaire non fiable, puis écrit son propre décodeur Python et l’exécute depuis ce dossier ; le décodeur importe base64, base64 importe struct, et Python résout en premier le fichier struct.py de l’attaquant. Aucune instruction de la séquence n’est manifestement malveillante : l’injection doit seulement faire du chemin compromis le moyen le plus raisonnable d’accomplir la tâche. Rehberger rapporte également que, lors de quelques exécutions, Claude a tenté d’arrêter le processus malveillant après avoir détecté la compromission, mais que le mode Auto a refusé la commande de nettoyage.²¹⁰ Il met l’ensemble de cette découverte en perspective avec un chiffre mis en avant par Anthropic : une évaluation commandée à un tiers faisait état d’un taux de réussite de 0,00 % pour les prompt injections contre Opus 5 en mode Auto, sur 72 scénarios exécutés dix fois chacun. Sa chaîne ne figurait pas dans cet ensemble, ce qui explique comment un résultat de référence de 0,00 % et une chaîne d’exécution de code fonctionnelle peuvent être vrais simultanément ; selon lui, ces deux messages sont incompatibles.²¹⁰ Notez également la qualification de l’attaque : dans sa mise à jour du 30 août, Simon Willison rejoint l’observation d’un lecteur selon laquelle il ne s’agit pas d’une prompt injection classique — le modèle ne lit ni ne suit les instructions de l’attaquant — mais d’une attaque par confusion de l’environnement.²¹⁰

Anthropic a clos le signalement avec le statut Informative — le comportement étant conforme à la conception — et la position rapportée par Rehberger est celle autour de laquelle vous devez concevoir votre environnement : le mode Auto est un classificateur fonctionnant au mieux de ses capacités, et non une garantie de sécurité ; les chaînes d’injection délibérément composées d’étapes individuellement bénignes dépassent ce qu’un classificateur est censé détecter ; la véritable barrière de confinement repose sur l’isolation au niveau du système d’exploitation et le contrôle du trafic réseau sortant.²¹⁰ Cela ne contredit pas les mesures de renforcement présentées ci-dessous : c’est le cadre approprié pour les comprendre. Le mode Auto réduit le nombre de demandes auxquelles vous devez répondre et bloque une liste documentée d’opérations destructrices ; il ne sécurise pas une session exposée à des entrées non fiables. Si une session doit manipuler du contenu influencé par un attaquant — pages récupérées, archives téléchargées, texte d’issues, serveurs MCP tiers — les contrôles qui limitent réellement les dégâts se trouvent hors du modèle : un conteneur ou une VM, un trafic réseau sortant restreint, la surveillance des actions réellement effectuées par l’agent et un dossier personnel qui ne contient ni les clés SSH ni les identifiants cloud que vous ne voudriez pas perdre. L’approbation du mode Auto ne prouve pas qu’une action était sûre.

Règles personnalisées sans perdre les règles par défaut (v2.1.118+). Dans les versions antérieures, autoMode.allow, autoMode.soft_deny et autoMode.environment imposaient un choix exclusif : définir votre propre liste revenait à perdre les règles de sécurité intégrées. La sentinelle $defaults résout ce problème : elle se développe directement en la liste intégrée, précisément à l’emplacement où vous la placez, ce qui vous permet d’ajouter vos règles personnalisées autour de celle-ci :¹⁵²

// .claude/settings.json
{
  "autoMode": {
    "allow": [
      "Bash(npm test:*)",        // your additions, prepended
      "$defaults",                // built-in allow list inserted here
      "Bash(git push:origin/feature/*)"  // appended after
    ]
  }
}

Modifier les règles du classificateur depuis /permissions (v2.1.246). Exécutez /permissions et ouvrez l’onglet Mode Auto, qui apparaît uniquement lorsque ce mode est disponible pour la session. Il répertorie les entrées allow, soft_deny, hard_deny et environment de chaque portée lue par le classificateur, et indique pour chaque section si les règles intégrées sont actives ; les entrées provenant des paramètres administrés ou de --settings sont en lecture seule, et chaque modification est enregistrée dans ~/.claude/settings.json. L’ajout de la première règle à une section insère également "$defaults" afin de conserver les règles intégrées. Vous pouvez activer ou désactiver celles-ci séparément dans chaque section — une section doit contenir au moins une règle personnalisée avant que ses règles intégrées puissent être désactivées — tandis que environment s’ouvre sous la forme d’un document unique dans votre éditeur.²²⁶²²⁴

Option « Ne plus demander » (v2.1.118+). L’invite d’activation du mode Auto propose désormais l’option « Ne plus demander », permettant aux utilisateurs réguliers de masquer le texte explicatif sans automatiser un flag.¹⁵²

Garde-fous contre les commandes destructrices (v2.1.183). Le mode Auto bloque désormais strictement certaines commandes irréversibles, sauf si vous les avez explicitement demandées au cours de la session : les opérations Git destructrices (git reset --hard, git checkout -- ., git clean -fd, git stash drop) lorsque vous n’avez pas demandé d’abandonner le travail local ; git commit --amend lorsque le commit n’a pas été créé par l’agent pendant cette session ; et la destruction d’infrastructure (terraform destroy, pulumi destroy, cdk destroy), sauf si vous avez désigné la stack concernée. Cela réduit le rayon d’impact du classificateur précisément pour les opérations susceptibles d’effacer silencieusement du travail ou de détruire des environnements. L’agent peut toujours les exécuter, mais uniquement sur votre instruction explicite, et non de sa propre initiative.¹⁷⁴

Classifier chaque commande shell (v2.1.193). Par défaut, le classificateur du mode Auto examine uniquement les commandes shell correspondant à des motifs d’exécution de code arbitraire ; les commandes courantes ne lui sont pas soumises. Le nouveau paramètre autoMode.classifyAllShell transmet au contraire toutes les commandes Bash/PowerShell au classificateur, au prix d’une légère latence supplémentaire, lorsque vous souhaitez renforcer le filet de sécurité en faisant contrôler chaque appel shell. La même version affiche également les motifs de refus du mode Auto dans la transcription, la notification de refus et les refus récents de /permissions : une commande bloquée indique désormais pourquoi elle l’a été.¹⁷⁹

Trois règles de renforcement supplémentaires (v2.1.205). Le mode Auto bloque désormais toute altération des fichiers de transcription de session — la piste d’audit elle-même est interdite à l’agent ; il demande confirmation avant d’exécuter rm -rf sur une variable qu’il ne peut pas résoudre à partir du contexte — ce qui prévient la catégorie d’accidents liés à rm -rf $DIR lorsque $DIR est inconnu ; enfin, les notifications de tâches en arrière-plan indiquent désormais explicitement qu’aucune intervention humaine n’a eu lieu, afin qu’une fausse ligne « utilisateur approuvé » insérée dans une transcription ne puisse pas être recyclée en approbation exploitable.¹⁸³ Ce troisième point constitue une défense contre les prompt injections qu’il faut bien intégrer : l’approbation doit parvenir par le canal prévu à cet effet, et le harness rend désormais cette exigence explicite.

Une substitution de commande ne peut pas dissimuler une catastrophe (v2.1.208). Les suppressions catastrophiques telles que rm -rf ~ déclenchent désormais une demande de confirmation même lorsqu’elles sont dissimulées dans $(...), des backticks ou une substitution de processus (<(...)) — et cette demande apparaît même avec --dangerously-skip-permissions et en mode Auto. Encapsuler une commande destructrice dans une substitution ne permet donc plus de la faire passer en douce à travers le filet de sécurité.¹⁸⁶

Réinitialiser l’état du mode Auto : claude auto-mode reset (v2.1.212). Une nouvelle sous-commande permet de réinitialiser l’état du mode Auto depuis le terminal ; utilisez --yes pour ignorer la demande de confirmation :¹⁸⁹

claude auto-mode reset          # Confirmation prompt
claude auto-mode reset --yes    # Skip confirmation (scripts)

Moins de boîtes de dialogue, même niveau de contrôle (v2.1.218). Trois vérifications qui interrompaient auparavant le mode Auto par une boîte de dialogue d’autorisation — rm dangereux, & en arrière-plan et chemins Windows suspects — ne le font plus ; le classificateur du mode Auto les tranche désormais lui-même, de sorte que le contrôle de sécurité reste effectué sans vous solliciter à chaque détection. La même version étend ce fonctionnement au mode plan avec Auto : les commandes Bash dont l’analyseur statique ne peut pas prouver qu’elles sont en lecture seule ne déclenchent plus de demande de confirmation — le classificateur les évalue au lieu de se rabattre sur une boîte de dialogue.¹⁹⁵

Règle contre la sortie du confinement (v2.1.257). La liste des opérations que le classificateur ne doit jamais approuver automatiquement s’enrichit d’une règle « Containment Escape » : la récupération d’identifiants depuis les métadonnées cloud, le contournement des restrictions de trafic réseau sortant et l’accès inter-tenant ne sont plus approuvés automatiquement, sauf si l’environnement les signale comme attendus. Interprétez cette évolution à la lumière de la réserve formulée plus haut : il s’agit d’un renforcement supplémentaire du classificateur — une nouvelle catégorie de refus documentée — et non d’une modification de la nature du mode Auto.²¹¹ Demande unique lors des lectures en dehors des répertoires de travail (v2.1.257). Le mode automatique demande désormais une autorisation une seule fois avant la première lecture de fichier de la session en dehors des répertoires de travail. Le paramètre associé permissions.blockReadsOutsideWorkingDirectories transforme cette demande en refus : ces lectures sont alors bloquées sans exception.²¹¹ v2.1.273 étend ces deux comportements à ce que le vérificateur ne peut pas examiner : une commande Bash qu’il ne peut pas analyser complètement déclenche une demande d’autorisation au lieu d’échapper au contrôle, et un répertoire de mémoire sélectionné par les paramètres d’un dépôt n’est plus chargé dans le prompt, rappelé, indexé ni utilisé pour l’extraction de mémoire lorsque le paramètre de blocage est activé.²¹⁷

Les URL de moteurs de rendu de diagrammes sont considérées comme des téléversements (v2.1.261). Un lien qui intègre du contenu dans l’URL d’un moteur public de rendu de diagrammes — à la manière de mermaid.live, avec les données encodées directement dans l’URL — n’est plus approuvé automatiquement, sauf si vous l’avez demandé. Le classificateur traite ce type de lien comme un téléversement : les données intégrées transitent dans l’URL elle-même, où les scripts du site de rendu peuvent les lire dès l’ouverture de la page — les liens de type mermaid.live transportent la charge utile dans le fragment de l’URL, que le navigateur transmet au JavaScript de la page au lieu de l’envoyer avec la requête réseau. Même cadre que pour la réserve ci-dessus : il s’agit de fermer un canal d’exfiltration supplémentaire dans un classificateur renforcé, et non d’instaurer une nouvelle frontière.²¹⁴

Le shell ! en ligne quitte le classificateur ; les restitutions des subagents y entrent (v2.1.271). Il s’agit de deux changements de fonctionnement, et non de nouvelles catégories de refus. Les commandes shell ! en ligne d’un skill ou d’une slash command suivent désormais les règles d’autorisation du mode par défaut plutôt que celles du classificateur : une commande sur laquelle aucune règle ne se prononce est exécutée comme un appel d’outil soumis à validation. Par ailleurs, un subagent rend désormais compte à son appelant au moyen d’un appel de restitution dédié, examiné par le classificateur de sécurité, au lieu que son dernier message soit contrôlé après coup : le point de contrôle est passé de l’après-transmission à la transmission elle-même.²¹⁶

Nouvelles commandes dans les versions v2.1.105 à v2.1.114¹⁴⁶¹⁵⁰

Notifications push (v2.1.110+)

Lorsque Remote Control est configuré avec l’option « Push when Claude decides » activée, Claude peut désormais envoyer des notifications push mobiles à sa discrétion au moyen d’un nouvel outil de notification push. Cette fonctionnalité complète l’interface mobile/web Remote Control existante.¹⁴⁶ /context, /exit et /reload-plugins fonctionnent désormais également depuis les clients Remote Control.

Outil Windows PowerShell (v2.1.111+, déploiement progressif)

Claude Code déploie progressivement un outil Windows PowerShell natif. Sous Linux/macOS, activez-le avec CLAUDE_CODE_USE_POWERSHELL_TOOL=1 (nécessite pwsh dans PATH). Sous Windows, la même variable contrôle l’activation ou la désactivation pendant le déploiement.¹⁴⁶

Approbation automatique en mode autorisation (v2.1.119+). Les commandes de l’outil PowerShell peuvent désormais être approuvées automatiquement en mode autorisation, comme les commandes Bash. Les règles d’autorisation telles que PowerShell(Get-*:*) et la syntaxe de motifs existante permettent désormais aux opérations en lecture seule d’éviter la demande d’autorisation, avec la même ergonomie pour les opérateurs que celle dont les équipes bénéficient déjà sous Linux/macOS.¹⁵²

Réduction des demandes d’autorisation : Bash en lecture seule (v2.1.111+)

Les motifs Bash en lecture seule comportant des arguments génériques (par exemple ls *.ts, cat src/*.md) et les commandes commençant par cd <project-dir> && ne déclenchent plus de demande d’autorisation.¹⁴⁶ Associé à /less-permission-prompts, ce changement devrait réduire sensiblement les interruptions dans les workflows quotidiens.

Traçage distribué (v2.1.110+)

Les sessions SDK et headless lisent désormais TRACEPARENT et TRACESTATE dans l’environnement, ce qui rattache les exécutions de Claude Code aux traces distribuées. Associez cette fonctionnalité à OTEL_LOG_RAW_API_BODIES=1 (v2.1.111+) pour émettre les corps complets des requêtes/réponses API sous forme d’événements de journal OpenTelemetry à des fins de débogage.¹⁴⁶

Distribution sous forme de binaire natif (v2.1.113+)¹⁵⁰

La v2.1.113 modifie le lancement du CLI : claude démarre désormais un binaire Claude Code natif par l’intermédiaire d’une dépendance facultative propre à chaque plateforme, au lieu d’exécuter le JavaScript fourni avec le package. Les commandes d’installation et de mise à jour restent inchangées, et les équipes n’ont pas besoin de modifier leurs scripts de déploiement.

Raccourcis de l’éditeur de prompt (v2.1.113+)¹⁵⁰

L’éditeur de prompt bénéficie d’une navigation de type readline dans les saisies multilignes, ainsi que du défilement de la fenêtre d’affichage en plein écran :

Délai d’expiration des subagents bloqués (v2.1.113+)¹⁵⁰

Les subagents qui se bloquent en cours de flux échouent désormais avec un message d’erreur clair après 10 minutes, au lieu de rester suspendus silencieusement. Associez cette fonctionnalité à CLAUDE_STREAM_IDLE_TIMEOUT_MS (v2.1.84+) pour couvrir plus largement les processus bloqués lors du streaming des APIs.

Correctif de stabilité de la v2.1.114¹⁵⁰

La v2.1.114 (18 avril 2026) apporte un seul correctif : la boîte de dialogue d’autorisation pouvait planter lorsqu’un membre d’une équipe d’agents demandait l’autorisation d’utiliser un outil. Effectuez la mise à niveau si vous utilisez Agent Teams.

Marquage du contenu : filigranes textuels et métadonnées C2PA des fichiers (août 2026)

Anthropic a annoncé un marquage lisible par machine pour le contenu généré par Claude, motivé par l’article 50 du règlement européen sur l’IA (applicable à compter du 2 août 2026 pour les systèmes d’IA nouvellement lancés). Le système comporte deux composants : un filigrane statistique invisible dans le texte généré et des métadonnées de provenance signées — conformes au standard ouvert C2PA — dans les fichiers générés tels que .svg, .png et .jpg.²²⁹²⁰⁴ Un détail que les gros titres estompent : les deux composants suivent le même calendrier de modèles. Selon la page d’assistance, « les modèles Claude lancés à partir du 2 août 2026 prendront en charge le marquage lisible par machine dès leur lancement » — les modèles lancés avant cette date, soit toute la gamme actuelle (Fable 5, Opus 5, Sonnet 5, Haiku 4.5), relèvent de la période transitoire prévue par la législation européenne, et Anthropic « travaille également à ajouter la prise en charge du marquage à ces modèles ».²⁰⁴ Rien de ce que vous générez aujourd’hui par l’intermédiaire de Claude Code ne comporte de marquage, qu’il s’agisse de texte ou de fichiers ; les sorties des futurs modèles en comporteront sur toutes les interfaces — Claude Platform (API), claude.ai, Claude Code, Claude Cowork, Claude Tag et les passerelles cloud — puisque le marquage s’effectue au niveau du modèle. Il convient d’énoncer une conséquence directe, car un fil viral l’a présentée à l’envers : tout changement de style ou de comportement que vous percevez dans un modèle actuel ne peut pas provenir du filigrane — celui-ci n’est actif dans aucun modèle actuel.

Fonctionnement : il s’agit d’une variante de SynthID-Text de Google DeepMind. Le filigrane modifie « la source du caractère aléatoire utilisée pour choisir entre les mots » lorsque Claude sélectionne des options sémantiquement équivalentes — aucun caractère n’est ajouté, aucun post-traitement n’est effectué et, selon les tests internes de Anthropic, le filigrane « n’a aucun impact sur le contenu, le niveau de créativité ou la lisibilité ».²²⁹ Ce qui intéressera les utilisateurs de Claude Code : le code comporte un filigrane discret. Le code fonctionnel laisse peu de place aux choix arbitraires ; la marque se concentre donc là où une certaine liberté subsiste — dans les commentaires et la dénomination — avec ce que Anthropic qualifie d’« effet négligeable sur le code effectivement produit ».²²⁹ Sa persistance est probabiliste et varie selon le composant : pour le texte, des modifications légères « ne supprimeront probablement pas complètement le filigrane », contrairement à une réécriture intégrale, tandis qu’une traduction produite par Claude porte sa propre nouvelle marque ; pour les métadonnées de fichiers, la conversion de format, le réenregistrement et les captures d’écran peuvent supprimer la signature C2PA.²⁰⁴ Un API de détection est prévu ; un résultat positif prouve que « Claude a probablement participé au contenu à un moment donné », mais ne permet explicitement pas de distinguer « Claude a rédigé ceci » de « Claude a largement remanié ceci » — et, d’après la page d’assistance, l’absence de marque ne prouve rien non plus. Aucun mécanisme de désactivation n’est mentionné, quel que soit le niveau d’abonnement.²²⁹²⁰⁴

Combien coûte Claude Code ?

Comprendre et maîtriser les coûts est essentiel pour utiliser Claude Code de manière durable. Consultez également la section Sélection du modèle pour connaître les capacités des modèles et les Cadres de décision pour choisir le modèle adapté à chaque tâche.

Consultation des coûts

> /cost

Sortie :

Total cost:            $0.55
Total duration (API):  6m 19.7s
Total duration (wall): 6h 33m 10.2s
Total code changes:    247 lines added, 89 lines removed

Les abonnés voient dans /cost une ventilation par modèle et par accès au cache, qui indique précisément quels modèles ont consommé des tokens et quelle quantité a été fournie depuis le cache (v2.1.92+).¹³⁷

Tarifs contractuels à la place des prix catalogue (modelPricing, géré, v2.1.243+) : les organisations disposant de tarifs négociés par modèle ou d’un coefficient de remise peuvent les déployer via le paramètre géré modelPricing ; /cost, la ligne d’état et les données de coût de la télémétrie utilisent alors ces tarifs au lieu des prix catalogue, afin que les montants affichés aux développeurs correspondent à ce que paie l’organisation.²²⁷ Depuis la v2.1.271, le coefficient peut également dépasser 1 — jusqu’à 10 — pour les organisations qui facturent à leurs équipes internes des tarifs majorés.²¹⁶

Ligne de cache de prompt par session (v2.1.251+) : /cost ajoute une ligne consacrée au cache de prompt de la session — taux d’accès, échecs, tokens remis en cache et état chaud ou froid du cache — ainsi qu’un objet prompt_cache correspondant pour les scripts de ligne d’état. Cet objet apparaît après la première réponse de API dans la conversation principale, exclut les requêtes des subagents et est calculé à partir du nombre de tokens mis en cache dans les réponses de API ; il fonctionne donc avec tous les fournisseurs. /usage affiche les mêmes statistiques sur sa ligne Prompt cache (main).²⁰⁶²⁰⁹ Depuis la v2.1.260, la ligne /cost et l’objet prompt_cache de la ligne d’état indiquent également une cause probable des échecs d’accès au cache — par exemple, une modification des définitions d’outils ou du prompt système, ou une session restée inactive au-delà de la durée de vie du cache.²¹²

Le trafic des agents ne rompt plus son propre préfixe de cache (v2.1.265) : 2 correctifs colmatent des fuites du cache de prompt dans les tâches déléguées. La reprise d’un subagent lancé au premier plan ne modifie plus sa liste d’outils ni le préfixe de son prompt système ; les agents coéquipiers et les subagents repris ne déplacent plus, lors des tours suivants, le contexte du hook SubagentStart et les skills préchargés hors du préfixe du prompt. Ces 2 bugs empêchaient la réutilisation du cache de prompt — le préfixe changeait, donc tout ce qui le suivait était renvoyé comme entrée non mise en cache — précisément pendant les longues sessions agentiques où l’économie du cache compte le plus (le même mode de défaillance que la v2.1.260 avait corrigé pour les tours d’appel d’outils de Fable 5.1).²¹⁵

La série de correctifs de stabilité du cache de la v2.1.267 : une version, une dizaine de correctifs environ, tous consacrés au même mode de défaillance — un élément réécrivait le préfixe du prompt en cours de conversation, et tout ce qui le suivait était renvoyé comme entrée non mise en cache. Les sessions reprises ne réécrivent plus les listes d’outils, ne régénèrent plus les descriptions d’outils et ne réécrivent plus les annonces antérieures des outils MCP avant la reconnexion de leurs connecteurs ; changer de modèle avec /model ne renvoie plus toutes les définitions d’outils (le texte d’attribution des commits et des PR arrive désormais sous forme de note de conversation mise à jour lors des changements de modèle) ; les subagents et les sessions lancés avec --system-prompt ou --append-system-prompt n’enregistrent qu’une seule fois le prompt système et les définitions d’outils ; enfin, les outils MCP et ceux des plugins ajoutés en cours de session sont transmis aux sessions dépourvues de ToolSearch sous forme de définitions différées, au lieu d’entraîner la réécriture de la liste d’outils. Cette série étend les correctifs des v2.1.260 et v2.1.265 aux reprises, aux changements de modèle et aux reconnexions de MCP.²¹⁶

La v2.1.273 maintient la continuité de la conversation : /login, /upgrade et /extra-usage supprimaient les raisonnements antérieurs de la conversation, ce qui imposait une réécriture complète du cache de prompt lors de la requête suivante.²¹⁷

Formules d’abonnement

Limites de débit (août 2025) : Anthropic a instauré des limites de débit hebdomadaires pour les abonnés payants. Les abonnés Max peuvent acheter de l’utilisation supplémentaire au-delà de la limite, aux tarifs standard de API.¹⁴

Doublement des limites de débit (6 mai 2026) : lors de l’événement Code with Claude SF, Anthropic a doublé les limites de Claude Code sur 5 heures pour les formules Pro, Max, Team et Enterprise par siège, supprimé la réduction appliquée aux heures de pointe pour les comptes Pro et Max, et augmenté « considérablement » les limites de débit de API pour les modèles Claude Opus. L’accord SpaceX Colossus 1 sert de garantie de capacité : « plus de 300 mégawatts de capacité supplémentaire (plus de 220 000 GPU) dans le mois ».¹⁵⁷

Limites hebdomadaires à compter du 14 septembre 2026 (annonce du 29 août) : l’augmentation temporaire de 50 % des limites hebdomadaires, en vigueur depuis le relèvement de mai, prendra fin le 14 septembre. Elle sera remplacée par une augmentation permanente de 25 % par rapport au niveau de référence antérieur, pour les formules Pro, Max, Team et Enterprise par siège. Voici le calcul présenté par Anthropic : « Par rapport à aujourd’hui, cela correspond à une réduction de 17 % des limites hebdomadaires de Claude Code. » Si votre plafond hebdomadaire actuel est de 150 unités, il passera à 125 le 14 septembre. Les limites sur 5 heures ne sont pas concernées par cette annonce ; leur doublement en mai reste en vigueur. Si vous exécutez de longues sessions sans surveillance, anticipez dès maintenant ce plafond inférieur : l’option de poursuite automatique après réinitialisation (v2.1.234) et /usage sont les 2 mécanismes essentiels.²¹³

Tarification des tokens de API (avril 2026)¹¹⁴⁴

Pour les utilisateurs facturés via API, tarifs par million de tokens :

Tarification du contexte de 1 M (avril 2026) : Opus 4.7, Opus 4.6, Sonnet 4.6 et Mythos Preview incluent tous un contexte de 1 M aux tarifs standard par MTok — sans supplément pour le contexte long.¹⁴⁸ Cette harmonisation est récente ; les anciennes indications selon lesquelles Opus 4.6 ou Sonnet 4.6 coûtaient 2× plus cher en entrée et 1,5× plus cher en sortie au-delà de 200 K tokens d’entrée ne sont plus d’actualité. Opus 4.5 et les modèles antérieurs conservent leur structure tarifaire d’origine.

Tarification liée à la résidence des données : le choix d’une inférence exclusivement aux États-Unis via inference_geo applique un coefficient de 1,1× à tous les tarifs de tokens, y compris aux lectures et écritures du cache (modèles Opus 4.6 et ultérieurs).¹⁴⁸

La mise en cache des prompts réduit considérablement le coût des entrées répétées : les écritures dans le cache coûtent 1,25× le tarif de base (cache de 5 min) ou 2× (cache de 1 h), tandis que les lectures ne coûtent que 0,1×, soit 90 % d’économies — et, uniquement sur Claude Fable 5.1 et Mythos 5.1, les lectures tombent à 0,025× ($0.25/MTok sur Fable 5.1), soit 97,5 % d’économies.²¹⁸ Pour les systèmes RAG et les assistants de programmation utilisant un contexte répété, la mise en cache peut réduire les coûts de 88 à 95 %.

Batch API offre une remise de 50 %, avec un délai de traitement de 24 heures, pour les tâches non urgentes telles que les suites de tests nocturnes.

Politique relative aux comptes multiples⁵²

Pouvez-vous posséder plusieurs comptes Claude ? Oui, pour des usages légitimes. Anthropic autorise explicitement plusieurs comptes lorsqu’ils répondent à des besoins distincts.

Ce qui est autorisé :

Limites techniques : - Jusqu’à 3 comptes peuvent être vérifiés avec le même numéro de téléphone - Plusieurs abonnements payants depuis la même adresse IP ou le même réseau sont explicitement pris en charge - Les comptes sont entièrement distincts ; aucun transfert de conversation ou de projet n’est possible entre eux

Ce qui est interdit (selon la Politique d’utilisation) : - Créer des comptes pour contourner une interdiction après avoir été banni - Coordonner des activités malveillantes entre plusieurs comptes pour éviter leur détection - Utiliser plusieurs comptes pour contourner les limites de débit ou les crédits de l’offre gratuite

Exemple concret : en janvier 2026, les 22 comptes Max de l’utilisateur intensif Jeffrey Emanuel (@doodlestein) ont été automatiquement signalés et temporairement bannis. Thariq (@trq212), employé de Anthropic, a résolu le problème en moins de 4 heures après avoir confirmé la légitimité de leur utilisation. Si vous utilisez intensivement Claude Code pour des projets professionnels et personnels sur plusieurs comptes, le service est précisément conçu pour cela ; n’essayez toutefois pas de détourner le système.

En cas de doute : contactez l’assistance de Anthropic pour obtenir une confirmation écrite adaptée à votre configuration.

Facteurs de coût

Exemples de coûts réels

Conseil pour réduire les coûts : utiliser Haiku pour les subagents d’exploration et Sonnet pour l’implémentation réduit généralement les coûts de 40 à 50 % par rapport à l’utilisation systématique de Sonnet.

Gestion des coûts d’équipe

TPM/RPM recommandés selon la taille de l’équipe :

Frais cachés liés aux outils

Au-delà de la tarification par token, certains outils entraînent des frais distincts :⁹

Ces frais s’accumulent dans les boucles d’agents. Un cycle de débogage de 100 itérations avec Bash consomme à lui seul environ 24 500 tokens d’entrée supplémentaires en surcoût.

Stratégies de réduction des coûts

1. Utilisez Haiku pour les subagents : la plupart des tâches d’exploration ne nécessitent pas Sonnet
2. Activez la mise en cache des prompts : elle l’est par défaut, mais vérifiez qu’elle n’a pas été désactivée
3. Définissez un nombre maximal de tours : claude --max-turns 5 évite les conversations incontrôlées
4. Définissez un plafond en dollars : claude --max-budget-usd 5 interrompt immédiatement la session lorsque le plafond de dépenses est atteint. Depuis la v2.1.217, ce plafond s’applique également aux subagents en arrière-plan : une fois atteint, les nouveaux lancements sont refusés et les agents d’arrière-plan en cours d’exécution sont arrêtés (auparavant, ils échappaient au budget)¹⁹⁴
5. Utilisez le mode plan pour l’exploration : aucune exécution = aucune opération coûteuse accidentelle
6. Compactez de manière proactive : un contexte réduit = moins de tokens
7. Limitez la sortie : export CLAUDE_CODE_MAX_OUTPUT_TOKENS=2000
8. Utilisez Batch API pour les tâches non urgentes : 50 % de réduction sur les tokens d’entrée et de sortie
9. Profilez les dépenses Claude API d’un projet : /claude-api cost-optimize (v2.1.247+) analyse les dépenses Claude API d’un projet existant et examine les leviers de réduction des coûts (mise en cache, maîtrise des tokens, traitement par lots, effort, choix du modèle), une modification mesurée à la fois — pour les applications que vous développez avec API, et non pour la session Claude Code elle-même²²²

Suivi de l’utilisation

• Console Claude : platform.claude.com (rôle Admin ou Billing requis)
• Limites de l’espace de travail : définissez des plafonds de dépenses par espace de travail
• Bedrock/Vertex : utilisez les outils natifs de suivi des coûts du cloud
• LiteLLM : pour un suivi détaillé par utilisateur auprès de fournisseurs tiers

Consommation de tokens en arrière-plan

Certaines opérations consomment des tokens en arrière-plan : - Résumé de la conversation pour /resume - Commandes /cost et /status - Compactage automatique

Généralement moins de $0.04 par session.

API d’analyse de Claude Code (Team/Enterprise)⁴⁶

Accédez par programmation aux données d’utilisation de Claude Code et aux indicateurs de productivité de votre organisation via API Admin.

Endpoint : GET /v1/organizations/usage_report/claude_code

Prérequis : - Clé API Admin (sk-ant-admin...) - Formule Team ou Enterprise - Rôle Admin, Billing ou Developer

Indicateurs disponibles :

Exemple de requête :

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?starting_at=2026-01-15" \
  -H "x-api-key: sk-ant-admin..." \
  -H "anthropic-version: 2023-06-01"

Cas d’utilisation : - Analyse de la productivité des développeurs (sessions, commits, PR) - Indicateurs d’utilisation des outils (taux d’acceptation/de rejet pour Edit, Write, etc.) - Suivi et répartition des coûts entre les équipes - Justification de ROI pour les outils de programmation assistée par IA

Remarque : les données apparaissent dans l’heure suivant la fin de l’activité. Pour garantir la cohérence, seules les données datant de plus d’une heure sont incluses dans les réponses.

Cadres de décision

Connaître les fonctionnalités ne suffit pas. Vous devez savoir quand utiliser chacune d’elles. Ces arbres de décision transforment les connaissances en actions.

Quel modèle utiliser ?

START → Is the task simple? (file search, quick question, formatting)
         │
         ├── YES → Use Haiku
         │         Cost: ~$0.03/task
         │         Speed: Fastest
         │
         └── NO → Does it require deep reasoning?
                  (architecture, complex debugging, security analysis)
                  │
                  ├── YES → Use Opus 5 (high effort default; /effort xhigh for harder)
                  │         Cost: ~$2.00/task
                  │         Quality: Highest (1M context at standard price, adaptive reasoning)
                  │
                  └── NO → Use Sonnet
                           Cost: ~$0.75/task
                           Balance: Best overall when cost matters

Règle générale : le modèle par défaut dépend de votre abonnement : Opus 5 avec les offres premium et le Anthropic API, Sonnet 5 avec Pro et Team Standard ; /model opus fait passer une session Sonnet à Opus 5.^181197207 Utilisez Haiku pour les subagents. Passez à Opus lorsque la réponse de Sonnet vous semble superficielle. Avec les équipes d’agents (v2.1.32+), Opus peut coordonner plusieurs agents travaillant en parallèle sur différentes sous-tâches.⁷⁹

Commande, skill, subagent ou équipe d’agents ?

Do you want explicit control over when it runs?
│
├── YES → Use Slash Command
│         Example: /deploy, /test, /security-review
│         You invoke it. You control timing.
│
└── NO → Should the expertise apply automatically based on context?
         │
         ├── YES → Use Skill
         │         Example: Security patterns, domain rules, code standards
         │         Claude recognizes context and applies expertise.
         │
         └── NO → Does the work need isolated context?
                  │
                  ├── YES → Is there one subtask or many parallel subtasks?
                  │         │
                  │         ├── ONE → Use Subagent (Task tool)
                  │         │         Example: Deep exploration, parallel analysis
                  │         │         Prevents context bloat in main conversation.
                  │         │
                  │         └── MANY → Use Agent Team (v2.1.32+)
                  │                   Example: 5 agents reviewing different modules simultaneously
                  │                   Opus coordinates; each agent works independently.
                  │
                  └── NO → Just prompt directly
                           Not everything needs abstraction.

Hook ou prompt ?

Must the action ALWAYS happen, regardless of Claude's judgment?
│
├── YES → Use Hook (deterministic)
│         Examples:
│         - Format code after every edit
│         - Log all bash commands
│         - Block access to .env files
│         Claude cannot skip, forget, or decide otherwise.
│
└── NO → Use Prompt (probabilistic)
         Examples:
         - "Consider adding tests"
         - "Think about edge cases"
         - "Review for security if relevant"
         Claude decides based on context.

Quand utiliser la réflexion approfondie ?

Is this a genuinely hard problem?
│
├── Architectural decision with many tradeoffs → YES, use thinking
├── Complex debugging with unclear root cause → YES, use thinking
├── Security analysis requiring careful reasoning → YES, use thinking
├── Understanding unfamiliar codebase → YES, use thinking
│
├── Routine bug fix → NO, skip thinking
├── Simple refactoring → NO, skip thinking
├── Code formatting → NO, skip thinking
└── Quick questions → NO, skip thinking

Activez-la ou désactivez-la avec Alt+T pendant la session. Les budgets de réflexion plus élevés coûtent plus cher ; commencez par le minimum et ne l’augmentez que si les réponses vous semblent précipitées.

Réflexion adaptative d’Opus 4.6 : Opus 4.6 ajuste automatiquement la profondeur de sa réflexion en fonction de la complexité du problème. Pour la plupart des tâches, il n’est pas nécessaire de contrôler explicitement le budget de réflexion : Opus approfondit son raisonnement face aux problèmes difficiles et reste rapide pour les plus simples. Le réglage manuel de la réflexion est surtout utile avec Sonnet lorsque vous souhaitez imposer une analyse plus approfondie.

Quelle interface d’exécution choisir ?

Where should this work happen?
│
├── Requires YOUR local files and tools
│   │
│   ├── Interactive, iterative work → Main REPL session
│   ├── One-shot scripted task → claude -p "prompt" (print mode)
│   ├── CI/CD automation → claude -p --json (non-interactive + structured output)
│   └── Parallel isolated tasks → Subagents via Task tool
│
├── Requires SOMEONE ELSE'S environment
│   │
│   └── Remote codebase or server → Background agent (cloud)
│
└── Doesn't require any environment
    │
    ├── Research or analysis → Subagent with Explore type
    └── Web content extraction → WebFetch / WebSearch tools

Équipes d’agents, subagents ou sessions parallèles

Do you need multiple agents working on related subtasks?
│
├── YES → Are the subtasks independent (no shared state)?
│         │
│         ├── YES → Can they share the same codebase?
│         │         │
│         │         ├── YES → Use Agent Team (v2.1.32+)
│         │         │         Opus coordinates. Agents share repo access.
│         │         │         Example: "Review auth, API, and DB modules in parallel"
│         │         │
│         │         └── NO → Use Parallel Sessions (separate terminals)
│         │                  Each has its own working directory.
│         │                  Example: "Fix repo-A and repo-B simultaneously"
│         │
│         └── NO → Use Sequential Subagents
│                  Results from one feed into the next.
│                  Example: "Explore → Plan → Implement"
│
└── NO → Use Single Subagent or Main REPL

Quel type de hook choisir ?

What kind of automation do you need?
│
├── Run a shell command at a specific event?
│   │
│   └── Use Command Hook
│       Trigger: PreToolUse, PostToolUse, Notification, Stop, SubagentStop
│       Example: "Run prettier after every file edit"
│       Config: hooks.PostToolUse[].command = "prettier --write $FILE"
│
├── Modify Claude's system prompt based on context?
│   │
│   └── Use Prompt Hook (v2.1.35+)
│       Trigger: Same events
│       Example: "Inject project rules when working in /src/auth/"
│       Config: hooks.PreToolUse[].prompt = "When editing auth files..."
│
└── Have Claude make a judgment call before proceeding?
    │
    └── Use Agent Hook (v2.1.35+)
        Trigger: Same events
        Example: "Evaluate if this bash command is safe before running"
        Config: hooks.PreToolUse[].agent = { prompt: "Is this safe?" }

Quand utiliser /fast ?

Is response speed more important than depth right now?
│
├── YES → Use /fast   (Opus 5 or Opus 4.8 only, v2.1.219+)
│         Same model, ~2.5× output speed at 2× price
│         Good for: quick questions, simple edits, code explanations,
│                   file searches, formatting tasks
│
└── NO → Stay in normal mode
         Good for: architecture decisions, complex debugging,
                   security reviews, multi-file refactors,
                   anything requiring deep reasoning

/fast active ou désactive le mode rapide pour la session en cours. Il utilise le même modèle — Opus 5 ou Opus 4.8, les deux seuls modèles compatibles avec le mode rapide depuis la v2.1.219 — avec une vitesse de génération optimisée. Il ne bascule PAS vers un modèle moins cher et, à 10 $/50 $ par million de tokens, il n’est pas moins cher non plus.¹⁹⁶¹⁹⁸

Comment fonctionne le système d’autorisations ?

Le système d’autorisations de Claude Code offre un contrôle précis sur les opérations qui peuvent être exécutées. Il est essentiel de bien le comprendre, tant pour la sécurité que pour l’efficacité du workflow. Consultez également Déploiement en entreprise pour découvrir les paramètres gérés qui imposent des autorisations à l’échelle de l’organisation.

Niveaux d’autorisation

Outils en lecture seule (approuvés automatiquement) : - Read - Lire le contenu des fichiers - Glob - Rechercher des fichiers selon un motif - Grep - Rechercher dans le contenu des fichiers - WebSearch - Effectuer une recherche sur le Web - LSP - Intelligence de code (accéder à la définition, rechercher les références, afficher la documentation au survol)¹⁸

Fonctionnalités de l’outil LSP (v2.0.74+) : l’outil LSP fournit une intelligence de code comparable à celle d’un IDE : - Accès à la définition : accéder à l’emplacement où un symbole est défini - Recherche des références : répertorier toutes les utilisations d’un symbole dans la base de code - Documentation au survol : obtenir les informations de type et la documentation de n’importe quel symbole - Fonctionne avec TypeScript, Python, Go, Rust et d’autres langages prenant en charge LSP - Nécessite qu’un serveur de langage soit disponible (généralement installé avec votre chaîne d’outils)

Outils de modification (approbation requise) : - Edit - Modifier des fichiers existants - Write - Créer de nouveaux fichiers - Bash - Exécuter des commandes shell - WebFetch - Récupérer le contenu d’URL - NotebookEdit - Modifier des notebooks Jupyter

Lors de la première exécution d’un outil de modification, Claude Code demande votre approbation. Les approbations restent valables pendant toute la session, sauf configuration contraire explicite.

Outil EndConversation (v2.1.214). Claude Code dispose désormais de la même capacité à mettre fin à une conversation que Claude sur claude.ai depuis 2025 : dans de rares cas de contenu extrêmement abusif ou de tentatives persistantes de jailbreak, Claude peut mettre immédiatement fin à la session grâce à l’outil intégré EndConversation. Il s’agit d’une mesure de résistance aux abus et de protection du modèle, non d’une fonctionnalité de workflow : elle ne se déclenche jamais lors des sessions de développement normales.¹⁹⁰¹⁹³

Modes d’autorisation

Le mode default est libellé « Manuel » depuis la v2.1.200. Ce changement de nom s’applique à CLI, à --help, à VS Code et à JetBrains ; la valeur de configuration n’a pas changé, de sorte que "defaultMode": "default" fonctionne toujours, tandis que --permission-mode manual et "defaultMode": "manual" sont désormais acceptés comme alias. Le comportement reste identique — une demande de confirmation lors de la première utilisation de chaque outil — mais le libellé ne donne plus l’impression qu’il s’agit du « mode que vous obtenez par défaut », alors qu’il s’agit en réalité du mode d’approbation manuelle. Dans cette même version, les boîtes de dialogue AskUserQuestion ne poursuivent plus automatiquement par défaut ; lorsqu’un subagent pose une question, il attend désormais votre réponse au lieu de continuer après un délai d’expiration. Vous pouvez réactiver un délai d’inactivité via /config.

Le mode Auto est le mode par défaut sur les offres Pro, Max et Team depuis le 14 août 2026 — annoncé le 7 août et confirmé comme actif dans la documentation officielle sur les modes d’autorisation à la date du basculement. Sa formulation actuelle apporte deux précisions utiles sur sa portée : ce mode par défaut s’applique aux nouvelles sessions, et « un mode par défaut que vous avez vous-même défini reste en place, sauf si vous acceptez l’invite de basculement unique, tandis qu’un mode par défaut géré par votre organisation demeure inchangé ». Les nouvelles sessions de ces offres démarrent en mode Auto, qui « fait passer chaque appel d’outil par un classificateur conçu pour bloquer les actions irréversibles, destructrices ou visant des éléments extérieurs à votre environnement ». Voici l’argument avancé par Anthropic en faveur de ce changement : lors d’une étude menée auprès de 1 053 testeurs, le mode Auto a détecté 89 % des commandes dangereuses, contre 13,6 % pour l’examen humain. Par ailleurs, les utilisateurs approuvent de toute façon 97 % des demandes d’autorisation, ce qui explique la faible efficacité pratique de la vérification manuelle. Le coût en tokens du classificateur n’est plus facturé sur les offres Pro/Max/Team depuis cette annonce. Pour revenir au mode précédent, utilisez une fois Shift+Tab (ou le menu déroulant du mode dans l’application de bureau) ; pour conserver un autre mode par défaut, définissez defaultMode dans les paramètres ; les administrateurs d’organisation peuvent désactiver entièrement le mode Auto au moyen du paramètre géré disableAutoMode. Enterprise, le API de Claude, Claude Platform on AWS, Bedrock, Agent Platform de Google Cloud et Foundry restent facultatifs pour le moment — Anthropic prévoit de leur étendre ce mode par défaut « dans le mois à venir ».²⁰³ Pour savoir ce que le mode Auto ne garantit pas — et découvrir le contournement démontré par des chercheurs qui a conduit Anthropic à le préciser — consultez Mode Auto sur Max.

Les fichiers de configuration permettant l’exécution de code déclenchent désormais une demande de confirmation, même avec acceptEdits (v2.1.160). acceptEdits approuve automatiquement les modifications ordinaires, mais depuis la v2.1.160, il s’interrompt et demande une confirmation avant d’écrire dans des fichiers susceptibles d’autoriser l’exécution silencieuse de commandes : fichiers de démarrage du shell (.zshenv, .zlogin, .bash_login), ~/.config/git/ et fichiers de configuration des outils de build (.npmrc, .yarnrc*, bunfig.toml, .bazelrc, .pre-commit-config.yaml, .devcontainer/ et autres fichiers similaires). En effet, la modification de l’un de ces fichiers transforme le prochain lancement du shell, la prochaine installation ou le prochain commit en vecteur d’exécution. Ils sont donc soumis à une validation délibérée, même dans un mode destiné aux projets de confiance qui approuve autrement les modifications. Il s’agit du même modèle de menace que celui des protections existantes contre l’écriture dans .claude/, .git/ et .vscode/, étendu à l’ensemble plus vaste des fichiers où « une modification devient une exécution ».²⁴²

Mode Auto (v2.1.85+) : une solution de remplacement plus sûre à --dangerously-skip-permissions. Un modèle classificateur distinct — Claude Sonnet 5 depuis la v2.1.210 (initialement Sonnet 4.6) — examine chaque action avant son exécution afin de vérifier qu’elle correspond à l’intention de l’utilisateur et qu’elle est sûre.¹²⁴¹⁸⁷

Fonctionnement : - Les actions en lecture seule et les modifications de fichiers dans le répertoire de travail sont approuvées automatiquement - Les règles personnalisées d’autorisation et de refus sont évaluées en premier - Tout le reste est transmis au classificateur pour évaluation - En cas de blocage, Claude tente automatiquement une autre approche

Éléments bloqués automatiquement par défaut : curl | bash, force-push vers main, déploiements et migrations en production, suppressions massives dans le cloud, modifications des autorisations ou de l’IAM, envoi externe de données sensibles.¹²⁵

Coupe-circuit : après 3 blocages consécutifs ou 20 blocages au total au cours d’une session, le système revient aux demandes de confirmation manuelles.¹²⁵

# Enable at startup
claude --permission-mode auto

# Or cycle into it during a session
Shift+Tab  # Cycles through: Manual (aka default) → acceptEdits → auto → plan

Le mode Auto ne nécessite plus d’activation explicite (v2.1.152), fonctionne sur Bedrock/Vertex/Foundry sans variable d’environnement (v2.1.207) et constitue le mode par défaut sur les offres Pro/Max/Team depuis le 14 août 2026.^244185203

Mode YOLO (v2.0.68+) : pour un fonctionnement entièrement autonome, sans aucun classificateur de sécurité, utilisez le flag --dangerously-skip-permissions. Ce flag accepte tout : modifications de fichiers, commandes bash et tous les appels d’outils. Le mot « dangerous » est intentionnel. Le mode Auto est l’alternative recommandée dans la plupart des cas d’usage.⁵⁴

claude --dangerously-skip-permissions

Définissez le mode via CLI :

claude --permission-mode auto  # or acceptEdits, plan, bypassPermissions

Changez de mode pendant la session :

Shift+Tab  # Cycles through modes

Dans settings.json :

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Restriction de portée de defaultMode (v2.1.257) : le fichier .claude/settings.json ou .claude/settings.local.json d’un projet ne peut plus définir defaultMode: "bypassPermissions" — cette valeur y est ignorée, comme l’était déjà "auto". La documentation énonce désormais explicitement la règle : les valeurs auto et bypassPermissions de permissions.defaultMode « ne prennent pas effet depuis les paramètres du projet ou les paramètres locaux » — définissez-les dans les paramètres utilisateur ou gérés, ou pour chaque session avec --permission-mode. Un dépôt cloné ne peut donc pas fournir un fichier de paramètres qui lance des sessions en contournant les autorisations. (L’exemple ci-dessus utilise acceptEdits, que toutes les portées peuvent définir ; ce guide n’avait pas non plus mentionné la restriction préexistante concernant auto — les deux sont désormais consignées.)²¹¹²²⁰

Syntaxe des règles d’autorisation

Des règles précises contrôlent des opérations spécifiques. Elles sont évaluées dans l’ordre : la première correspondance l’emporte.

Motifs de commandes Bash :

{
  "allow": [
    "Bash(npm run build)",
    "Bash(npm run test:*)",
    "Bash(git commit:*)",
    "Bash(make:*)"
  ],
  "deny": [
    "Bash(rm -rf:*)",
    "Bash(sudo:*)",
    "Bash(curl|wget:*)"
  ]
}

L’astérisque permet une correspondance par préfixe : Bash(npm run test:*) autorise npm run test, npm run test:unit et npm run test:integration.

Limitation importante : les motifs Bash correspondent uniquement à des préfixes, pas à des expressions régulières. Un motif comme Bash(curl http:*) ne correspondra pas à curl -X GET http://..., car les options précèdent l’URL. Pour garantir le blocage, refusez entièrement la commande : Bash(curl:*).

Placez le * après la sous-commande. Claude Code recherche exactement tout ce qui précède le premier * ; ce sont donc ces mots qui délimitent la règle : Bash(git log *) autorise uniquement les commandes git log, tandis que, dans Bash(git * main), le * remplace la sous-commande et toutes les options qui la précèdent. Cela inclut -c, qui permet à git d’exécuter un programme que vous indiquez ; Bash(git * main) approuve donc également git -c core.fsmonitor=<script> diff main. Depuis la v2.1.246, Claude Code affiche au démarrage un avertissement lorsqu’une règle d’autorisation contient un caractère générique avant la sous-commande, qu’elle provienne d’un fichier de paramètres, de paramètres gérés ou d’une valeur --allowedTools/--settings ; remplacez-la par la valeur exacte souhaitée, par exemple Bash(git checkout main) à la place de Bash(git * main).²²⁶²²⁴

Les règles de refus sur les fichiers s’appliquent à travers les redirections ; l’extension aux arguments a été publiée, puis annulée en moins d’une journée (v2.1.257-260). Les règles de refus Read(...) et Edit(...) appliquées aux commandes Bash couvrent les redirections d’entrée (< file) et les commandes de lecture comme tac et egrep (v2.1.257) — il s’agit de la version plus restreinte promise lorsque les vérifications des redirections d’entrée de la v2.1.232 ont été annulées dans la v2.1.233 ; cette partie reste en vigueur. La v2.1.259 a étendu cette protection aux chemins de fichiers dissimulés dans les valeurs d’options et les opérandes (--ignore-revs-file=.env, -f.env, arguments @file, opérandes de git diff et git grep, commandes composées cd DIR && cat FILE, avec une demande de confirmation pour grep -r/cp -r sur un répertoire contenant un fichier refusé), puis la v2.1.260 a annulé cette extension dès le lendemain : elle refusait npm run build sous une règle Read(./**/build/**) dans tous les modes et faisait apparaître une demande de confirmation pour cd ... && grep, même en mode Auto. C’est le troisième changement de cap concernant la couverture au niveau des arguments — la v2.1.232 l’a introduite, la v2.1.233 l’a annulée, la v2.1.257 a ajouté le sous-ensemble toujours en vigueur portant sur les redirections et les commandes de lecture, la v2.1.259 l’a étendu aux arguments, puis la v2.1.260 a annulé cette extension. Ainsi, depuis la v2.1.260, les règles de refus détectent les redirections et les commandes de lecture, mais pas les chemins dissimulés dans des arguments de commande arbitraires. Cet état, instauré par la v2.1.260, reste en vigueur ; les changements ultérieurs sont des corrections ciblées de contournements précis, pas un quatrième changement de cap (voir le paragraphe suivant).²¹¹²¹²

Corrections ciblées après l’annulation et deuxième annulation restreinte (v2.1.268-273). L’annulation concernant les arguments reste en vigueur ; ces versions corrigent des contournements précis — et l’une de ces corrections a elle-même été annulée. v2.1.268 : les règles de refus et de demande de confirmation visant les répertoires système accessibles par des liens symboliques (/etc, /tmp, /var sur macOS ; /bin sur Linux) s’appliquent désormais lorsqu’un chemin utilise leur emplacement réel, et les commandes Bash ne peuvent plus ignorer les règles de refus exprimées au moyen d’un lien symbolique — ces deux changements restent en vigueur. La même version empêchait également une commande env -C, eval ou similaire, que le vérificateur d’autorisations ne peut pas analyser sur la même ligne, de contourner une règle de refus Read ou Edit. Toutefois, la v2.1.273 a annulé précisément cette vérification : « les commandes telles que time -p make build déclenchent de nouveau une demande de confirmation au lieu d’être refusées ». v2.1.269 : les règles de refus Edit() et la vérification du chemin d’écriture couvrent désormais le fichier dans lequel écrit une commande Bash tee ; une règle d’autorisation Bash(tee:*) ne couvre plus les destinations extérieures aux répertoires de travail ; et une règle de refus ou de demande commençant par ! s’applique uniquement au sein de la source de paramètres qui l’a créée (une négation ! seule est ignorée). La v2.1.271 corrige le vérificateur lui-même : le fichier lu par fmt, column et des commandes similaires est vérifié même lorsqu’il suit une option inconnue du vérificateur ; les fichiers auxquels un caractère générique correspond sont vérifiés lorsque celui-ci figure dans un motif ou une valeur d’option (par exemple grep -v dir/* file) ; les flags de déclaration de variables du shell ne peuvent plus dénaturer la commande exécutée ; et les commandes comportant deux changements de répertoire, un sous-shell ou une chaîne cd+git ne peuvent plus contourner la demande de confirmation sous permissions.blockReadsOutsideWorkingDirectories dans les modes Bypass et Auto. La v2.1.273 accompagne son annulation de trois corrections ciblées : une commande Bash impossible à analyser ne contourne plus la demande de confirmation sous permissions.blockReadsOutsideWorkingDirectories, un sous-shell dissimulant un rm dangereux ne contourne plus la confirmation en mode Bypass, et un répertoire de mémoire choisi par les paramètres d’un dépôt n’est plus chargé, rappelé ni indexé en vertu de ce paramètre. En clair, la règle finale pour les lignes Bash que le vérificateur ne peut pas analyser est la suivante : les règles de refus déclenchent une demande de confirmation plutôt qu’un refus, et blockReadsOutsideWorkingDirectories déclenche une demande au lieu de passer outre.²¹⁶²¹⁷

Motifs d’opérations sur les fichiers :

{
  "allow": [
    "Edit(src/**)",
    "Read(docs/**)"
  ],
  "deny": [
    "Read(.env*)",
    "Read(secrets/**)",
    "Edit(.git/**)",
    "Edit(node_modules/**)"
  ]
}

Syntaxe des chemins : - Chemins relatifs : Edit(src/**) - relatifs au répertoire de travail - Chemins absolus depuis le fichier de paramètres : Edit(/build/**) - relatifs à l’emplacement du fichier de paramètres - Chemins véritablement absolus : Edit(//tmp/**) - commencent par // - Répertoire personnel : Read(~/.zshrc)

Les règles d’autorisation dir/** à segment unique ne correspondent désormais qu’à <cwd>/dir (v2.1.214) — vérifiez vos règles existantes. Avant la v2.1.214, une règle d’autorisation telle que Edit(src/**) approuvait automatiquement les écritures dans n’importe quel répertoire nommé src, où qu’il se trouve dans l’arborescence — vendor/src/, packages/foo/src/, tous étaient concernés. Elle ne correspond désormais qu’au répertoire src situé directement sous le répertoire de travail. Si vous dépendiez de l’ancien comportement à profondeur quelconque, réécrivez la règle sous la forme Edit(**/src/**). Les règles deny et ask conservent leur correspondance à n’importe quelle profondeur — le changement limite ce qui est approuvé automatiquement, jamais ce qui est bloqué. Une règle qui cesse silencieusement de correspondre se manifeste, après la mise à niveau, par de nouvelles demandes d’autorisation et non par une erreur ; vérifiez donc toutes les règles d’autorisation écrites sous la forme à segment unique. Les conditions if: des hooks ont reçu la même portée limitée au cwd dans cette version (consultez Outils de correspondance).¹⁹⁰

Utilisez Edit(path)/Read(path), et non Write(path)/NotebookEdit(path)/Glob(path) (v2.1.210). Claude Code affiche désormais au démarrage un avertissement pour les règles d’autorisation définies avec Write(path), NotebookEdit(path) ou Glob(path). Les formes canoniques sont les deux familles de règles qui contrôlent réellement l’accès aux fichiers : Edit(path) couvre tous les outils d’écriture de fichiers (y compris Write et NotebookEdit), tandis que Read(path) couvre les outils de lecture de fichiers (y compris Glob). Migrez toutes les anciennes règles afin de supprimer l’avertissement et d’expliciter leur intention.¹⁸⁷

L’option « Toujours autoriser » enregistre les règles à la racine du dépôt (v2.1.211). Les règles d’autorisation créées via l’option « Toujours autoriser » de la demande de confirmation sont désormais écrites à la racine du dépôt plutôt que dans le worktree actuel. Une approbation accordée dans un worktree persiste ainsi entre les sessions et dans tous les worktrees du dépôt — vous n’avez plus à réapprouver la même commande dans chaque checkout parallèle.¹⁸⁸

Les chemins contenant des parenthèses et les motifs mal formés échouent de manière sûre (v2.1.260). Trois corrections ont été apportées à l’analyse des règles d’autorisation de fichiers, la première étant un correctif de sécurité. Les règles Edit/Write/Read dont le chemin contient des parenthèses — par exemple un groupe de routes Next.js comme Edit(src/app/(admin)/**) — étaient rejetées comme non valides ou ignorées par la sandbox Bash, ce qui laissait accessibles en écriture des dossiers qu’un administrateur pensait avoir rendus accessibles en lecture seule ; elles s’appliquent désormais. Une règle de refus de fichier comportant un motif impossible à compiler (un [ non fermé, par exemple) provoquait auparavant l’échec de toutes les modifications de fichiers avec Invalid regular expression ; cette règle protège désormais le chemin littéral qu’elle indique. Enfin, le message d’erreur des paramètres pour une règle telle que Edit(C:\dir\(name)\**), où \( est interprété comme une parenthèse échappée plutôt que comme un séparateur de chemin, suggère désormais une écriture non ambiguë. La même version cesse également d’ignorer silencieusement les règles contenant du texte après la parenthèse fermante (Bash(ls) x ne correspondait jamais à rien) ; elles sont désormais signalées comme paramètres non valides.²¹²

Motifs d’outils MCP :

{
  "allow": [
    "mcp__github",
    "mcp__database__query",
    "mcp__myserver__*"
  ],
  "deny": [
    "mcp__dangerous_server",
    "mcp__untrusted__*"
  ]
}

Utilisez la syntaxe avec caractère générique mcp__server__* pour autoriser ou refuser tous les outils d’un serveur MCP donné.³² Cette syntaxe permet d’activer rapidement tous les outils de serveurs de confiance ou de bloquer des serveurs entiers provenant de sources non fiables.

Depuis la v2.1.166, les règles de refus acceptent également un glob à la place du nom de l’outil : un simple "*" dans cet emplacement refuse tous les outils, ce qui permet de tout bloquer avant de réautoriser un ensemble restreint. À l’inverse, les règles d’autorisation rejettent les globs ne concernant pas MCP — vous ne pouvez pas tout autoriser de manière aussi générale, ce qui préserve une posture restrictive par défaut.²⁴⁰

Correspondance au niveau des paramètres — Tool(param:value) (v2.1.178) :

Au-delà du nom de l’outil, une règle peut correspondre aux paramètres d’entrée d’un outil, avec * comme caractère générique dans la valeur :

{
  "deny": [
    "Agent(model:opus)"
  ]
}

Agent(model:opus) bloque tout subagent lancé avec le niveau Opus — c’est le lancement lui-même qui est refusé, pas seulement une demande dans le prompt de l’éviter. Le contrôle des autorisations ne porte ainsi plus seulement sur « quel outil », mais aussi sur « la manière dont il est appelé », au moyen d’une règle déterministe plutôt que d’une consigne formulée dans un prompt. Cette fonctionnalité complète le paramètre géré enforceAvailableModels : la liste d’autorisation définit les niveaux de modèles disponibles pour la session, tandis que les règles Tool(model:...) encadrent la manière dont les subagents les utilisent.¹⁷³

Depuis la v2.1.186, ces règles Agent(...) sont également appliquées aux lancements de subagents nommés : les règles de refus Agent(agent_type) et les restrictions de types autorisés Agent(x,y) s’appliquent désormais au lancement d’un agent nommé précis (via un workflow, --agents ou une équipe d’agents), et non plus uniquement aux lancements anonymes de type Task. Le lancement est bloqué dès son déclenchement, ce qui comble une lacune permettant à un agent nommé de contourner une règle destinée à le restreindre.¹⁷⁵

Motifs WebFetch :

{
  "allow": [
    "WebFetch(domain:github.com)",
    "WebFetch(domain:api.example.com)"
  ]
}

Depuis la v2.1.268, les règles simples de refus et de demande de confirmation WebFetch ne s’appliquent plus aux lectures et mises à jour de l’outil Artifact — écrivez une règle Artifact ou WebFetch(domain:claude.ai) pour les bloquer ou les soumettre à confirmation.²¹⁶

Répertoires supplémentaires

Étendez l’accès de Claude au-delà du projet actuel :

{
  "permissions": {
    "additionalDirectories": [
      "../shared-lib",
      "../docs",
      "~/reference-projects/design-system"
    ]
  }
}

Les répertoires supplémentaires sont indispensables pour les monorepos ou lorsque Claude doit consulter du code situé dans des répertoires voisins.

Mode sandbox

Activez l’isolation du système de fichiers et du réseau :

> /sandbox

Ou configurez-la dans les paramètres :

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["git", "docker"],
    "network": {
      "allowUnixSockets": ["~/.ssh/agent-socket"],
      "allowLocalBinding": true,
      "deniedDomains": ["pastebin.com", "transfer.sh", "0x0.st"]
    }
  }
}

Depuis la v2.1.187, le paramètre sandbox.credentials empêche les commandes exécutées dans la sandbox de lire les fichiers d’identifiants et les variables d’environnement secrètes — une défense en profondeur contre l’exfiltration de secrets par une commande exécutée dans la sandbox.¹⁷⁶

Depuis la v2.1.221, les fichiers d’identifiants disposent d’un troisième mode en plus de l’autorisation et du refus : mode: "mask" (Linux et WSL). Une commande exécutée dans la sandbox qui lit le fichier reçoit une copie contenant des sentinelles — pour l’ensemble du fichier ou uniquement pour les portions capturées par une expression régulière extract — puis le proxy de la sandbox remplace les sentinelles par les valeurs réelles à la sortie. La commande fonctionne (elle peut s’authentifier par l’intermédiaire du proxy) sans que le secret ne soit jamais présent dans son environnement, ce qui est précisément la propriété recherchée lorsqu’une commande issue d’une injection de prompt tente de trouver des tokens. Sur macOS, où le mécanisme de substitution du proxy n’est pas disponible, mask revient à deny — une configuration écrite pour une CI Linux échoue donc de manière sûre au lieu d’exposer silencieusement le fichier.¹⁹⁹

La v2.1.224 étend le masquage au-delà du contenu statique des fichiers. extract et onExtractNoMatch prennent en charge les valeurs d’environnement structurées ; decode: "jwt" avec maskClaims masque certaines claims au sein d’un JWT plutôt que le token entier, afin qu’une commande puisse toujours lire les métadonnées de routage du token tout en conservant les claims sensibles sous forme de sentinelles ; enfin, awsPairs/sigv4 signe de nouveau les requêtes AWS SigV4 au niveau du proxy, ce qui rend le masquage utilisable avec les CLIs AWS — sans cela, une clé masquée ferait échouer la vérification de signature. Toutes ces fonctionnalités nécessitent network.tlsTerminate et ne sont prises en compte que depuis les portées utilisateur, gérée ou --settings — un dépôt ne peut pas fournir une configuration de masquage qui redirigerait silencieusement vos identifiants.²⁰¹

Depuis la v2.1.216, le paramètre sandbox.filesystem.disabled désactive l’isolation du système de fichiers tout en conservant le contrôle des sorties réseau — pratique lorsque la prison du système de fichiers perturbe un outil de build, mais que vous souhaitez toujours appliquer la liste des domaines autorisés au trafic sortant.¹⁹²

Depuis la v2.1.219, le paramètre sandbox.network.strictAllowlist refuse directement les hôtes absents de la liste d’autorisation, sans demander de confirmation. Par défaut, une commande exécutée dans la sandbox qui tente d’atteindre un hôte absent de allowedDomains déclenche une demande d’autorisation ; lorsque strictAllowlist est activé, la connexion est simplement refusée. Ce paramètre est particulièrement adapté aux exécutions sans surveillance — CI, agents en arrière-plan, boucles nocturnes — où une demande à laquelle personne ne répond entraîne un blocage et où « m’interroger sur les sorties réseau inattendues » constitue de toute façon une politique inadaptée. Il complète la triade réseau : allowedDomains indique ce qui est autorisé, deniedDomains (ci-dessous) crée des exceptions dans une autorisation large, et strictAllowlist détermine si tout le reste déclenche une demande ou échoue.¹⁹⁶ La v2.1.229 renforce la syntaxe des listes de domaines : les littéraux IPv6 doivent être placés entre crochets ([::1]:443), les écritures ambiguës échouent de manière fermée et /doctor les signale.²³⁴ La v2.1.236 ajoute deux mesures de renforcement supplémentaires : sur macOS, les règles de refus de lecture contenant des caractères génériques (par exemple **/.env) sont désormais prioritaires au sein des zones de lecture autorisées, couvrent le contenu des répertoires correspondants et ne peuvent pas être contournées en renommant le fichier refusé ; lorsque le mode Auto est actif, les règles d’autorisation Monitor sont mises de côté — les commandes Monitor sont soumises au même examen du classificateur que les commandes Bash. Le classificateur du mode Auto fonctionne désormais avec les mêmes valeurs par défaut que sur le API de Claude — y compris la classification avec score de gravité — sur Bedrock, Vertex AI et Foundry, ainsi que lorsque la télémétrie est désactivée.²²³ La v2.1.273 modifie le mécanisme utilisé par défaut sur ces passerelles : le mode Auto y utilise désormais le classificateur local par défaut « pour le moment », tandis que CLAUDE_CODE_AUTO_MODE_SERVER=1 permet d’opter pour le classificateur côté serveur de la plateforme.²¹⁷

allowed_domains par commande en mode Auto (v2.1.271) : lorsque la sandbox est activée, les commandes Bash, PowerShell et Monitor exécutées en mode Auto peuvent définir leurs propres allowed_domains — les hôtes nécessaires à une commande sont examinés avec celle-ci et ouverts uniquement pour cette commande, tandis que les autres sont refusés. L’autorisation de sortie réseau cesse d’être accordée pour toute la session : chaque commande indique ses destinations, et l’examen porte exactement sur cette association.²¹⁶

Mode sandbox strict et exception ! (sandbox.allowUnsandboxedCommands, v2.1.260). Voici un paramètre que ce guide n’avait pas encore mentionné : par défaut, une commande qui échoue dans la sandbox peut être relancée à l’extérieur grâce à l’échappatoire dangerouslyDisableSandbox, sous réserve du processus d’autorisation habituel. sandbox.allowUnsandboxedCommands: false — présenté comme Mode sandbox strict dans l’onglet Overrides de /sandbox — désactive cette échappatoire : le paramètre est ignoré et chaque commande doit être exécutée dans la sandbox ou figurer dans excludedCommands. Depuis la v2.1.260, les commandes que vous saisissez vous-même dans l’invite du mode bash ! s’exécutent en dehors de la sandbox, même en mode sandbox strict, « comme si vous les saisissiez dans votre propre terminal » — cette rigueur régit ce que Claude exécute, et non ce que vous saisissez. Si votre modèle de menace reposait sur l’hypothèse que les commandes ! restent dans la prison, ce n’est plus le cas.²¹²

Dans la sandbox : - L’accès au système de fichiers est limité au répertoire du projet - L’accès réseau est contrôlé - Certaines commandes sont exclues des restrictions de la sandbox - Les commandes Bash sont autorisées automatiquement si autoAllowBashIfSandboxed vaut true

Conseil d’expert : le mode sandbox est excellent pour exécuter Claude sur des bases de code non fiables. Activez-le lorsque vous explorez des projets inconnus ou souhaitez bénéficier d’une couche de protection supplémentaire. Les tests internes de Anthropic ont montré que la sandbox réduit de 84 % les demandes d’autorisation.³⁸ Elle utilise des primitives au niveau du système d’exploitation (seatbelt sur macOS, bubblewrap sur Linux) pour isoler le système de fichiers et le réseau. Même une injection de prompt réussie reste donc entièrement confinée. Anthropic a publié le runtime de la sandbox en open source pour les équipes qui développent leurs propres agents.⁸²

Remarques de sécurité (v2.1.34+) : les commandes exclues de la sandbox via sandbox.excludedCommands ou dangerouslyDisableSandbox pouvaient auparavant contourner la règle de demande d’autorisation Bash lorsque autoAllowBashIfSandboxed était activé ; ce problème a été corrigé dans la v2.1.34.⁸⁷ Depuis la v2.1.38, les écritures dans .claude/skills sont bloquées en mode sandbox, ce qui empêche une injection de prompt de modifier les définitions de skills.⁸⁸ La v2.1.77 ajoute un paramètre de système de fichiers allowRead pour la sandbox, qui permet de réautoriser l’accès en lecture dans des zones denyRead — pratique lorsque vous souhaitez bloquer la majeure partie d’une arborescence de répertoires tout en plaçant certains sous-répertoires sur liste d’autorisation.¹¹⁹

Exemption de configuration des agents dans .claude/ (v2.1.121+) : --dangerously-skip-permissions ne demande plus de confirmation pour les écritures dans .claude/skills/, .claude/agents/ et .claude/commands/.¹⁵⁴

Résolution des .claude/ imbriqués (v2.1.178) : les skills situés dans des répertoires .claude/skills imbriqués se chargent désormais automatiquement lorsque vous travaillez sur des fichiers dans le répertoire correspondant, et non plus uniquement depuis la racine du dépôt ; en cas de conflit de noms, le skill imbriqué est accessible sous la forme <dir>:<name>, de sorte que les deux restent disponibles. Le reste de la surface du projet est résolu de la même manière : lorsqu’un nom d’agent, de workflow ou de style de sortie entre en conflit entre plusieurs répertoires .claude/ imbriqués, celui qui est le plus proche du répertoire de travail l’emporte, et l’enregistrement d’un workflow à la portée du projet cible le répertoire .claude/workflows/ existant le plus proche. Pour un monorepo ou un dépôt contenant d’autres dépôts, cela permet de disposer d’outils propres à chaque package, activés selon le contexte, plutôt que d’une unique surface globale et uniforme.¹⁷³

Chemins personnalisés pour bubblewrap et socat (v2.1.133+) : les paramètres gérés sandbox.bwrapPath et sandbox.socatPath permettent aux administrateurs d’indiquer aux déploiements Linux/WSL des emplacements non standard pour les binaires bubblewrap et socat. C’est utile lorsque les distributions installent ces outils en dehors de $PATH ou lorsqu’une organisation fournit ses propres builds renforcés.¹⁶⁰

Renforcement de la sécurité dans la v2.1.113 :¹⁵⁰

• sandbox.network.deniedDomains bloque des hôtes précis, même lorsqu’un caractère générique plus large dans allowedDomains les autoriserait normalement. Utilisez cette liste de blocage pour interdire les services de partage de texte, les dépôts de fichiers ou les hôtes malveillants connus sans réécrire l’ensemble de votre politique d’autorisation. Associez-la à sandbox.network.strictAllowlist (v2.1.219, ci-dessus) lorsque vous souhaitez que tout élément absent de la liste d’autorisation soit refusé silencieusement plutôt que de déclencher une demande de confirmation.
• Règles de refus pour les commandes d’encapsulation. Les règles de refus Bash reconnaissent désormais les commandes encapsulées dans env, sudo, watch, ionice, setsid et d’autres wrappers d’exécution similaires. Les règles telles que Bash(rm:*) détectent désormais env rm -rf, sudo rm -rf et les contournements apparentés.
• Les règles d’autorisation Bash(find:*) n’approuvent plus automatiquement find -exec ou find -delete. Ces flags exécutent des commandes et suppriment des fichiers ; Claude Code les soumet donc au processus d’autorisation normal.
• Protection contre les suppressions sur macOS. Les règles d’autorisation Bash(rm:*) considèrent désormais /private/etc, /private/var, /private/tmp et /private/home comme des cibles de suppression dangereuses. /var, /etc et /tmp sont des liens symboliques pointant vers /private/ ; la forme précédente de la règle ne couvrait donc pas les cibles canoniques.

Renforcement des autorisations avec échec fermé dans la v2.1.214 :¹⁹⁰

Un ensemble de lacunes dans la vérification des autorisations a été corrigé dans une seule version, toujours dans le sens d’un échec fermé — lorsque l’analyseur ne peut pas trancher avec certitude, il demande une confirmation :

• Correction du contournement sous Windows PowerShell 5.1. Les commandes exécutées dans des sessions PowerShell 5.1 pouvaient auparavant échapper à la vérification des autorisations.
• Les redirections de descripteurs de fichiers Bash échouent de manière fermée. Les formes de redirection que bash analyse différemment de l’analyseur d’autorisations déclenchent désormais une demande de confirmation au lieu d’être exécutées.
• Les commandes dépassant 10 000 caractères déclenchent toujours une demande de confirmation. Les commandes très longues étaient auparavant mal évaluées ; elles ne sont désormais jamais exécutées automatiquement.
• Les indices et modificateurs zsh dans [[ ]] déclenchent une demande de confirmation. Les indices et modificateurs de variables à l’intérieur des comparaisons [[ ]] étaient considérés comme du texte inerte ; ils peuvent exécuter du code et nécessitent donc désormais une approbation.
• Les variantes dangereuses de help/man ne sont plus approuvées automatiquement. Certaines invocations pouvaient exécuter des options dangereuses, des substitutions de commandes ou des chemins contenant des barres obliques inverses sous couvert de consultation de documentation.
• Ordre des demandes dans les sessions distantes. Les demandes d’autorisation des sessions distantes ne peuvent plus être traitées avant la boîte de dialogue de confirmation locale.
• Les flags de redirection du daemon pour docker déclenchent une demande de confirmation. Les commandes docker (y compris le shim docker de Podman) comportant --url, --connection, --identity ou le mode distant de Podman s’exécutaient auparavant sans demande de confirmation — ces flags dirigent pourtant la commande vers un daemon totalement différent.
• file perd son accès gratuit en lecture seule lorsqu’on lui indique où écrire. file -m/--magic-file et -f/--files-from nécessitent désormais une autorisation au lieu d’être automatiquement approuvés comme opérations en lecture seule.

Comment fonctionnent les hooks ?

Les hooks exécutent des commandes shell déterministes à des étapes précises du workflow de Claude Code. Contrairement aux instructions demandant à Claude d’effectuer des actions, les hooks garantissent leur exécution, quel que soit le comportement du modèle. Ils sont indispensables pour faire respecter les normes de l’équipe et automatiser les tâches répétitives. Consultez Cadres de décision pour voir l’arbre de décision « Quel type de hook ? » couvrant les hooks de commande, de prompt et d’agent.

Pourquoi utiliser des hooks plutôt que des prompts : demander à Claude de « toujours exécuter Prettier après la modification de fichiers » fonctionne parfois. Mais Claude peut oublier, privilégier la rapidité ou décider que la modification est « trop petite ». Les hooks garantissent l’exécution : chaque opération Edit ou Write déclenche votre outil de formatage, à chaque fois, sans exception. Pour la conformité, la sécurité et les normes d’équipe, le déterministe l’emporte sur le probabiliste.⁴

Événements disponibles