Passer au contenu principal
Claude Code offre une variété de paramètres pour configurer son comportement selon vos besoins. Vous pouvez configurer Claude Code en exécutant la commande /config lors de l’utilisation du REPL interactif, ce qui ouvre une interface Paramètres avec onglets où vous pouvez afficher les informations d’état et modifier les options de configuration.

Portées de configuration

Claude Code utilise un système de portées pour déterminer où les configurations s’appliquent et qui les partage. Comprendre les portées vous aide à décider comment configurer Claude Code pour un usage personnel, une collaboration d’équipe ou un déploiement en entreprise.

Portées disponibles

PortéeEmplacementQui est affectéPartagé avec l’équipe ?
ManagedParamètres gérés par le serveur, plist / registre, ou managed-settings.json au niveau systèmeTous les utilisateurs de la machineOui (déployé par l’IT)
UserRépertoire ~/.claude/Vous, dans tous les projetsNon
Project.claude/ dans le référentielTous les collaborateurs de ce référentielOui (commité dans git)
Local.claude/settings.local.jsonVous, dans ce référentiel uniquementNon (ignoré par gitignore)

Quand utiliser chaque portée

La portée Managed est pour :
  • Les politiques de sécurité qui doivent être appliquées à l’échelle de l’organisation
  • Les exigences de conformité qui ne peuvent pas être contournées
  • Les configurations standardisées déployées par l’IT/DevOps
La portée User est idéale pour :
  • Les préférences personnelles que vous voulez partout (thèmes, paramètres d’éditeur)
  • Les outils et plugins que vous utilisez dans tous les projets
  • Les clés API et l’authentification (stockées de manière sécurisée)
La portée Project est idéale pour :
  • Les paramètres partagés par l’équipe (permissions, hooks, MCP servers)
  • Les plugins que toute l’équipe devrait avoir
  • La standardisation des outils entre collaborateurs
La portée Local est idéale pour :
  • Les remplacements personnels pour un projet spécifique
  • Tester les configurations avant de les partager avec l’équipe
  • Les paramètres spécifiques à la machine qui ne fonctionneront pas pour les autres

Comment les portées interagissent

Quand le même paramètre est configuré dans plusieurs portées, les portées plus spécifiques ont la priorité :
  1. Managed (la plus élevée) - ne peut pas être contournée par quoi que ce soit
  2. Arguments de ligne de commande - remplacements de session temporaires
  3. Local - remplace les paramètres de projet et d’utilisateur
  4. Project - remplace les paramètres d’utilisateur
  5. User (la plus basse) - s’applique quand rien d’autre ne spécifie le paramètre
Par exemple, si une permission est autorisée dans les paramètres utilisateur mais refusée dans les paramètres de projet, le paramètre de projet a la priorité et la permission est bloquée.

Ce qui utilise les portées

Les portées s’appliquent à de nombreuses fonctionnalités de Claude Code :
FonctionnalitéEmplacement utilisateurEmplacement projetEmplacement local
Settings~/.claude/settings.json.claude/settings.json.claude/settings.local.json
Subagents~/.claude/agents/.claude/agents/Aucun
MCP servers~/.claude.json.mcp.json~/.claude.json (par projet)
Plugins~/.claude/settings.json.claude/settings.json.claude/settings.local.json
CLAUDE.md~/.claude/CLAUDE.mdCLAUDE.md ou .claude/CLAUDE.mdCLAUDE.local.md

Fichiers de paramètres

Le fichier settings.json est le mécanisme officiel pour configurer Claude Code via des paramètres hiérarchiques :
  • Les paramètres utilisateur sont définis dans ~/.claude/settings.json et s’appliquent à tous les projets.
  • Les paramètres de projet sont enregistrés dans votre répertoire de projet :
    • .claude/settings.json pour les paramètres qui sont vérifiés dans le contrôle de source et partagés avec votre équipe
    • .claude/settings.local.json pour les paramètres qui ne sont pas vérifiés, utiles pour les préférences personnelles et l’expérimentation. Claude Code configurera git pour ignorer .claude/settings.local.json quand il est créé.
  • Paramètres gérés : Pour les organisations qui ont besoin d’un contrôle centralisé, Claude Code supporte plusieurs mécanismes de livraison pour les paramètres gérés. Tous utilisent le même format JSON et ne peuvent pas être contournés par les paramètres utilisateur ou de projet :
    • Paramètres gérés par le serveur : livrés depuis les serveurs d’Anthropic via la console d’administration Claude.ai. Voir paramètres gérés par le serveur.
    • Politiques MDM/au niveau du système d’exploitation : livrées via la gestion native des appareils sur macOS et Windows :
      • macOS : domaine de préférences gérées com.anthropic.claudecode. Les clés de niveau supérieur du plist reflètent managed-settings.json, avec les paramètres imbriqués comme dictionnaires et les tableaux comme tableaux plist. Déployez via des profils de configuration dans Jamf, Iru (Kandji), ou d’autres outils MDM similaires.
      • Windows : clé de registre HKLM\SOFTWARE\Policies\ClaudeCode avec une valeur Settings (REG_SZ ou REG_EXPAND_SZ) contenant du JSON (déployé via Group Policy ou Intune)
      • Windows (au niveau utilisateur) : HKCU\SOFTWARE\Policies\ClaudeCode (priorité de politique la plus basse, utilisée uniquement quand aucune source au niveau administrateur n’existe)
    • Basé sur fichier : managed-settings.json et managed-mcp.json déployés dans les répertoires système :
      • macOS : /Library/Application Support/ClaudeCode/
      • Linux et WSL : /etc/claude-code/
      • Windows : C:\Program Files\ClaudeCode\
      Le chemin Windows hérité C:\ProgramData\ClaudeCode\managed-settings.json n’est plus supporté à partir de v2.1.75. Les administrateurs qui ont déployé des paramètres à cet emplacement doivent migrer les fichiers vers C:\Program Files\ClaudeCode\managed-settings.json.
      Les paramètres gérés basés sur fichier supportent également un répertoire drop-in à managed-settings.d/ dans le même répertoire système à côté de managed-settings.json. Cela permet à des équipes séparées de déployer des fragments de politique indépendants sans coordonner les modifications d’un seul fichier. Suivant la convention systemd, managed-settings.json est fusionné en premier comme base, puis tous les fichiers *.json dans le répertoire drop-in sont triés alphabétiquement et fusionnés par-dessus. Les fichiers ultérieurs remplacent les fichiers antérieurs pour les valeurs scalaires ; les tableaux sont concaténés et dédupliqués ; les objets sont fusionnés en profondeur. Les fichiers cachés commençant par . sont ignorés. Utilisez des préfixes numériques pour contrôler l’ordre de fusion, par exemple 10-telemetry.json et 20-security.json.
    Voir paramètres gérés et Configuration MCP gérée pour plus de détails. Ce référentiel inclut des modèles de déploiement de démarrage pour Jamf, Iru (Kandji), Intune, et Group Policy. Utilisez-les comme points de départ et ajustez-les selon vos besoins.
    Les déploiements gérés peuvent également restreindre les ajouts de marketplace de plugins en utilisant strictKnownMarketplaces. Pour plus d’informations, voir Restrictions de marketplace gérées.
  • Autre configuration est stockée dans ~/.claude.json. Ce fichier contient vos préférences (thème, paramètres de notification, mode d’éditeur), session OAuth, configurations de MCP server pour les portées utilisateur et locale, état par projet (outils autorisés, paramètres de confiance), et divers caches. Les MCP servers au niveau du projet sont stockés séparément dans .mcp.json.
Claude Code crée automatiquement des sauvegardes horodatées des fichiers de configuration et conserve les cinq sauvegardes les plus récentes pour prévenir la perte de données.
Exemple settings.json
{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Read(~/.zshrc)"
    ],
    "deny": [
      "Bash(curl *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  },
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp"
  },
  "companyAnnouncements": [
    "Welcome to Acme Corp! Review our code guidelines at docs.acme.com",
    "Reminder: Code reviews required for all PRs",
    "New security policy in effect"
  ]
}
La ligne $schema dans l’exemple ci-dessus pointe vers le schéma JSON officiel pour les paramètres Claude Code. L’ajouter à votre settings.json active l’autocomplétion et la validation en ligne dans VS Code, Cursor, et tout autre éditeur qui supporte la validation de schéma JSON. Le schéma publié est mis à jour périodiquement et peut ne pas inclure les paramètres ajoutés dans les versions CLI les plus récentes, donc un avertissement de validation sur un champ récemment documenté ne signifie pas nécessairement que votre configuration est invalide.

Paramètres disponibles

settings.json supporte un certain nombre d’options :
CléDescriptionExemple
agentExécuter le thread principal en tant que subagent nommé. Applique l’invite système, les restrictions d’outils et le modèle de ce subagent. Voir Invoquer les subagents explicitement"code-reviewer"
allowedChannelPlugins(Paramètres gérés uniquement) Liste blanche des plugins de channel qui peuvent envoyer des messages. Remplace la liste blanche Anthropic par défaut quand défini. Non défini = revenir à la valeur par défaut, tableau vide = bloquer tous les plugins de channel. Nécessite channelsEnabled: true. Voir Restreindre quels plugins de channel peuvent s’exécuter[{ "marketplace": "claude-plugins-official", "plugin": "telegram" }]
allowedHttpHookUrlsListe blanche des modèles d’URL que les hooks HTTP peuvent cibler. Supporte * comme caractère générique. Quand défini, les hooks avec des URL non correspondantes sont bloqués. Non défini = pas de restriction, tableau vide = bloquer tous les hooks HTTP. Les tableaux fusionnent entre les sources de paramètres. Voir Configuration des hooks["https://hooks.example.com/*"]
allowedMcpServersQuand défini dans managed-settings.json, liste blanche des MCP servers que les utilisateurs peuvent configurer. Non défini = pas de restrictions, tableau vide = verrouillage. S’applique à toutes les portées. La liste noire a la priorité. Voir Configuration MCP gérée[{ "serverName": "github" }]
allowManagedHooksOnly(Paramètres gérés uniquement) Seuls les hooks gérés, les hooks SDK, et les hooks des plugins force-activés dans les paramètres gérés enabledPlugins sont chargés. Les hooks utilisateur, projet et tous les autres hooks de plugin sont bloqués. Voir Configuration des hookstrue
allowManagedMcpServersOnly(Paramètres gérés uniquement) Seul allowedMcpServers à partir des paramètres gérés est respecté. deniedMcpServers fusionne toujours à partir de toutes les sources. Les utilisateurs peuvent toujours ajouter des MCP servers, mais seule la liste blanche définie par l’administrateur s’applique. Voir Configuration MCP géréetrue
allowManagedPermissionRulesOnly(Paramètres gérés uniquement) Empêcher les paramètres utilisateur et projet de définir les règles de permission allow, ask, ou deny. Seules les règles dans les paramètres gérés s’appliquent. Voir Paramètres gérés uniquementtrue
alwaysThinkingEnabledActiver la réflexion étendue par défaut pour toutes les sessions. Généralement configuré via la commande /config plutôt que d’éditer directementtrue
apiKeyHelperScript personnalisé, à exécuter dans /bin/sh, pour générer une valeur d’authentification. Cette valeur sera envoyée comme en-têtes X-Api-Key et Authorization: Bearer pour les demandes de modèle/bin/generate_temp_api_key.sh
attributionPersonnalisez l’attribution pour les commits git et les pull requests. Voir Paramètres d’attribution{"commit": "🤖 Generated with Claude Code", "pr": ""}
autoMemoryDirectoryRépertoire personnalisé pour le stockage de la mémoire automatique. Accepte les chemins développés avec ~/. Non accepté dans les paramètres de projet (.claude/settings.json) pour empêcher les référentiels partagés de rediriger les écritures de mémoire vers des emplacements sensibles. Accepté à partir des paramètres de politique, locaux et utilisateur"~/my-memory-dir"
autoModePersonnalisez ce que le classificateur du mode auto bloque et autorise. Contient les tableaux environment, allow, et soft_deny de règles en prose. Incluez la chaîne littérale "$defaults" dans un tableau pour hériter des règles intégrées à cette position. Voir Configurer le mode auto. Non lu à partir des paramètres de projet partagés{"soft_deny": ["$defaults", "Never run terraform apply"]}
autoUpdatesChannelCanal de version à suivre pour les mises à jour. Utilisez "stable" pour une version généralement une semaine ancienne et qui ignore les versions avec des régressions majeures, ou "latest" (par défaut) pour la version la plus récente"stable"
availableModelsRestreindre les modèles que les utilisateurs peuvent sélectionner via /model, --model, ou ANTHROPIC_MODEL. N’affecte pas l’option Par défaut. Voir Restreindre la sélection de modèle["sonnet", "haiku"]
awaySummaryEnabledAfficher un récapitulatif de session d’une ligne quand vous revenez au terminal après quelques minutes d’absence. Définir à false ou désactiver le récapitulatif de session dans /config pour désactiver. Identique à CLAUDE_CODE_ENABLE_AWAY_SUMMARYtrue
awsAuthRefreshScript personnalisé qui modifie le répertoire .aws (voir configuration avancée des identifiants)aws sso login --profile myprofile
awsCredentialExportScript personnalisé qui génère du JSON avec les identifiants AWS (voir configuration avancée des identifiants)/bin/generate_aws_grant.sh
blockedMarketplaces(Paramètres gérés uniquement) Liste noire des sources de marketplace. Appliquée lors de l’ajout de marketplace et lors de l’installation, la mise à jour, l’actualisation et la mise à jour automatique du plugin, donc une marketplace ajoutée avant que la politique soit définie ne peut pas être utilisée pour récupérer les plugins. Les sources bloquées sont vérifiées avant le téléchargement, donc elles ne touchent jamais le système de fichiers. Voir Restrictions de marketplace gérées[{ "source": "github", "repo": "untrusted/plugins" }]
channelsEnabled(Paramètres gérés uniquement) Autoriser les channels pour les utilisateurs Team et Enterprise. Non défini ou false bloque la livraison des messages de channel indépendamment de ce que les utilisateurs passent à --channelstrue
cleanupPeriodDaysLes sessions inactives pendant plus longtemps que cette période sont supprimées au démarrage (par défaut : 30 jours, minimum 1). Définir à 0 est rejeté avec une erreur de validation. Contrôle également le seuil d’âge pour la suppression automatique des worktrees de subagent orphelins au démarrage. Pour désactiver complètement les écritures de transcript, définissez la variable d’environnement CLAUDE_CODE_SKIP_PROMPT_HISTORY, ou en mode non interactif (-p) utilisez l’indicateur --no-session-persistence ou l’option SDK persistSession: false.20
companyAnnouncementsAnnonce à afficher aux utilisateurs au démarrage. Si plusieurs annonces sont fournies, elles seront affichées aléatoirement.["Welcome to Acme Corp! Review our code guidelines at docs.acme.com"]
defaultShellShell par défaut pour les commandes ! de la boîte d’entrée. Accepte "bash" (par défaut) ou "powershell". Définir à "powershell" achemine les commandes ! interactives via PowerShell sur Windows. Nécessite CLAUDE_CODE_USE_POWERSHELL_TOOL=1. Voir Outil PowerShell"powershell"
deniedMcpServersQuand défini dans managed-settings.json, liste noire des MCP servers qui sont explicitement bloqués. S’applique à toutes les portées y compris les servers gérés. La liste noire a la priorité sur la liste blanche. Voir Configuration MCP gérée[{ "serverName": "filesystem" }]
disableAllHooksDésactiver tous les hooks et toute ligne d’état personnaliséetrue
disableAutoModeDéfinir à "disable" pour empêcher l’activation du mode auto. Supprime auto du cycle Shift+Tab et rejette --permission-mode auto au démarrage. Très utile dans les paramètres gérés où les utilisateurs ne peuvent pas le contourner"disable"
disableDeepLinkRegistrationDéfinir à "disable" pour empêcher Claude Code d’enregistrer le gestionnaire de protocole claude-cli:// auprès du système d’exploitation au démarrage. Les liens profonds permettent aux outils externes d’ouvrir une session Claude Code avec une invite pré-remplie via claude-cli://open?q=.... Le paramètre q supporte les invites multi-lignes en utilisant des sauts de ligne codés en URL (%0A). Utile dans les environnements où l’enregistrement du gestionnaire de protocole est restreint ou géré séparément"disable"
disabledMcpjsonServersListe des MCP servers spécifiques à partir des fichiers .mcp.json à rejeter["filesystem"]
disableSkillShellExecutionDésactiver l’exécution de shell en ligne pour !`...` et ```! blocs dans les skills et les commandes personnalisées à partir des sources utilisateur, projet, plugin ou répertoire supplémentaire. Les commandes sont remplacées par [shell command execution disabled by policy] au lieu d’être exécutées. Les skills bundlés et gérés ne sont pas affectés. Très utile dans les paramètres gérés où les utilisateurs ne peuvent pas le contournertrue
effortLevelPersister le niveau d’effort entre les sessions. Accepte "low", "medium", "high", ou "xhigh". Écrit automatiquement quand vous exécutez /effort avec l’une de ces valeurs. Voir Ajuster le niveau d’effort pour les modèles supportés"xhigh"
enableAllProjectMcpServersApprouver automatiquement tous les MCP servers définis dans les fichiers .mcp.json du projettrue
enabledMcpjsonServersListe des MCP servers spécifiques à partir des fichiers .mcp.json à approuver["memory", "github"]
envVariables d’environnement qui seront appliquées à chaque session{"FOO": "bar"}
fastModePerSessionOptInQuand true, le mode rapide ne persiste pas entre les sessions. Chaque session commence avec le mode rapide désactivé, nécessitant que les utilisateurs l’activent avec /fast. La préférence de mode rapide de l’utilisateur est toujours enregistrée. Voir Exiger l’opt-in par sessiontrue
feedbackSurveyRateProbabilité (0–1) que l’enquête de qualité de session apparaisse quand elle est admissible. Définir à 0 pour supprimer complètement. Utile lors de l’utilisation de Bedrock, Vertex, ou Foundry où le taux d’échantillonnage par défaut ne s’applique pas0.05
fileSuggestionConfigurez un script personnalisé pour l’autocomplétion de fichier @. Voir Paramètres de suggestion de fichier{"type": "command", "command": "~/.claude/file-suggestion.sh"}
forceLoginMethodUtilisez claudeai pour restreindre la connexion aux comptes Claude.ai, console pour restreindre la connexion aux comptes Claude Console (facturation d’utilisation d’API)claudeai
forceLoginOrgUUIDExiger que la connexion appartienne à une organisation spécifique. Accepte une seule chaîne UUID, qui pré-sélectionne également cette organisation lors de la connexion, ou un tableau d’UUID où n’importe quelle organisation listée est acceptée sans pré-sélection. Quand défini dans les paramètres gérés, la connexion échoue si le compte authentifié n’appartient pas à une organisation listée ; un tableau vide échoue fermé et bloque la connexion avec un message de mauvaise configuration"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" ou ["xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"]
forceRemoteSettingsRefresh(Paramètres gérés uniquement) Bloquer le démarrage de la CLI jusqu’à ce que les paramètres gérés distants soient fraîchement récupérés du serveur. Si la récupération échoue, la CLI se termine plutôt que de continuer avec les paramètres en cache ou aucun paramètre. Quand non défini, le démarrage continue sans attendre les paramètres distants. Voir application fail-closedtrue
hooksConfigurez des commandes personnalisées à exécuter lors d’événements du cycle de vie. Voir documentation des hooks pour le formatVoir hooks
httpHookAllowedEnvVarsListe blanche des noms de variables d’environnement que les hooks HTTP peuvent interpoler dans les en-têtes. Quand défini, le allowedEnvVars effectif de chaque hook est l’intersection avec cette liste. Non défini = pas de restriction. Les tableaux fusionnent entre les sources de paramètres. Voir Configuration des hooks["MY_TOKEN", "HOOK_SECRET"]
includeCoAuthoredByDéprécié : Utilisez attribution à la place. S’il faut inclure la ligne co-authored-by Claude dans les commits git et les pull requests (par défaut : true)false
includeGitInstructionsInclure les instructions de workflow de commit et PR intégrées et l’instantané du statut git dans l’invite système de Claude (par défaut : true). Définir à false pour supprimer les deux, par exemple lors de l’utilisation de vos propres skills de workflow git. La variable d’environnement CLAUDE_CODE_DISABLE_GIT_INSTRUCTIONS a la priorité sur ce paramètre quand elle est définiefalse
languageConfigurez la langue de réponse préférée de Claude (par exemple, "japanese", "spanish", "french"). Claude répondra dans cette langue par défaut. Définit également la langue de la dictée vocale"japanese"
minimumVersionPlancher qui empêche les auto-mises à jour de fond et claude update d’installer une version inférieure à celle-ci. Passer du canal "latest" à "stable" via /config vous invite à rester sur la version actuelle ou à autoriser la rétrogradation. Choisir de rester définit cette valeur. Également utile dans les paramètres gérés pour épingler une version minimale à l’échelle de l’organisation"2.1.100"
modelRemplacer le modèle par défaut à utiliser pour Claude Code"claude-sonnet-4-6"
modelOverridesMapper les ID de modèle Anthropic aux ID de modèle spécifiques au fournisseur tels que les ARN de profil d’inférence Bedrock. Chaque entrée du sélecteur de modèle utilise sa valeur mappée lors de l’appel de l’API du fournisseur. Voir Remplacer les ID de modèle par version{"claude-opus-4-6": "arn:aws:bedrock:..."}
otelHeadersHelperScript pour générer des en-têtes OpenTelemetry dynamiques. S’exécute au démarrage et périodiquement (voir En-têtes dynamiques)/bin/generate_otel_headers.sh
outputStyleConfigurez un style de sortie pour ajuster l’invite système. Voir documentation des styles de sortie"Explanatory"
permissionsVoir le tableau ci-dessous pour la structure des permissions.
plansDirectoryPersonnalisez où les fichiers de plan sont stockés. Le chemin est relatif à la racine du projet. Par défaut : ~/.claude/plans"./plans"
pluginTrustMessage(Paramètres gérés uniquement) Message personnalisé ajouté à l’avertissement de confiance du plugin affiché avant l’installation. Utilisez ceci pour ajouter du contexte spécifique à l’organisation, par exemple pour confirmer que les plugins de votre marketplace interne sont vérifiés."All plugins from our marketplace are approved by IT"
prefersReducedMotionRéduire ou désactiver les animations de l’interface utilisateur (spinners, shimmer, effets flash) pour l’accessibilitétrue
respectGitignoreContrôler si le sélecteur de fichier @ respecte les modèles .gitignore. Quand true (par défaut), les fichiers correspondant aux modèles .gitignore sont exclus des suggestionsfalse
showClearContextOnPlanAcceptAfficher l’option « effacer le contexte » sur l’écran d’acceptation du plan. Par défaut : false. Définir à true pour restaurer l’optiontrue
showThinkingSummariesAfficher les résumés de réflexion étendue dans les sessions interactives. Quand non défini ou false (par défaut en mode interactif), les blocs de réflexion sont redactés par l’API et affichés comme un stub réduit. La redaction change uniquement ce que vous voyez, pas ce que le modèle génère : pour réduire les dépenses de réflexion, réduisez le budget ou désactivez la réflexion à la place. Le mode non interactif (-p) et les appelants SDK reçoivent toujours les résumés indépendamment de ce paramètretrue
skipWebFetchPreflightIgnorer la vérification de sécurité du domaine WebFetch qui envoie chaque nom d’hôte demandé à api.anthropic.com avant la récupération. Définir à true dans les environnements qui bloquent le trafic vers Anthropic, tels que les déploiements Bedrock, Vertex AI, ou Foundry avec une sortie restrictive. Quand ignorée, WebFetch tente n’importe quelle URL sans consulter la liste de blocagetrue
spinnerTipsEnabledAfficher les conseils dans le spinner pendant que Claude travaille. Définir à false pour désactiver les conseils (par défaut : true)false
spinnerTipsOverrideRemplacer les conseils du spinner par des chaînes personnalisées. tips : tableau de chaînes de conseil. excludeDefault : si true, afficher uniquement les conseils personnalisés ; si false ou absent, les conseils personnalisés sont fusionnés avec les conseils intégrés{ "excludeDefault": true, "tips": ["Use our internal tool X"] }
spinnerVerbsPersonnalisez les verbes d’action affichés dans le spinner et les messages de durée de tour. Définir mode à "replace" pour utiliser uniquement vos verbes, ou "append" pour les ajouter aux valeurs par défaut{"mode": "append", "verbs": ["Pondering", "Crafting"]}
sshConfigsConnexions SSH à afficher dans la liste déroulante de l’environnement Desktop. Chaque entrée nécessite id, name, et sshHost ; sshPort, sshIdentityFile, et startDirectory sont optionnels. Quand défini dans les paramètres gérés, les connexions sont en lecture seule pour les utilisateurs. Lus à partir des paramètres gérés et utilisateur uniquement[{"id": "dev-vm", "name": "Dev VM", "sshHost": "user@dev.example.com"}]
statusLineConfigurez une ligne d’état personnalisée pour afficher le contexte. Voir documentation statusLine{"type": "command", "command": "~/.claude/statusline.sh"}
strictKnownMarketplaces(Paramètres gérés uniquement) Liste blanche des sources de marketplace de plugins. Non défini = pas de restrictions, tableau vide = verrouillage. Appliquée lors de l’ajout de marketplace et lors de l’installation, la mise à jour, l’actualisation et la mise à jour automatique du plugin, donc une marketplace ajoutée avant que la politique soit définie ne peut pas être utilisée pour récupérer les plugins. Voir Restrictions de marketplace gérées[{ "source": "github", "repo": "acme-corp/plugins" }]
tuiMoteur de rendu de l’interface utilisateur du terminal. Utilisez "fullscreen" pour le moteur de rendu alt-screen sans scintillement avec défilement virtualisé. Utilisez "default" pour le moteur de rendu classique d’écran principal. Définir via /tui"fullscreen"
useAutoModeDuringPlanSi le mode plan utilise la sémantique du mode auto quand le mode auto est disponible. Par défaut : true. Non lu à partir des paramètres de projet partagés. Apparaît dans /config comme « Utiliser le mode auto pendant le plan »false
viewModeMode d’affichage de transcript par défaut au démarrage : "default", "verbose", ou "focus". Remplace la sélection sticky /focus quand défini"verbose"
voiceParamètres de dictée vocale : enabled active la dictée, mode sélectionne "hold" ou "tap", et autoSubmit envoie l’invite à la libération de la touche en mode hold. Écrit automatiquement quand vous exécutez /voice. Nécessite un compte Claude.ai{ "enabled": true, "mode": "tap" }
voiceEnabledAlias hérité pour voice.enabled. Préférez l’objet voicetrue
wslInheritsWindowsSettings(Paramètres gérés Windows uniquement) Quand true, Claude Code sur WSL lit les paramètres gérés à partir de la chaîne de politique Windows en plus de /etc/claude-code, avec les sources Windows ayant la priorité. Honoré uniquement quand défini dans la clé de registre HKLM ou C:\Program Files\ClaudeCode\managed-settings.json, qui nécessitent tous deux l’administrateur Windows pour écrire. Pour que la politique HKCU s’applique également sur WSL, l’indicateur doit également être défini dans HKCU lui-même. N’a aucun effet sur Windows natiftrue

Paramètres de configuration globale

Ces paramètres sont stockés dans ~/.claude.json plutôt que dans settings.json. Les ajouter à settings.json déclenchera une erreur de validation de schéma.
CléDescriptionExemple
autoConnectIdeSe connecter automatiquement à un IDE en cours d’exécution quand Claude Code démarre à partir d’un terminal externe. Par défaut : false. Apparaît dans /config comme Auto-connect to IDE (external terminal) lors de l’exécution en dehors d’un terminal VS Code ou JetBrainstrue
autoInstallIdeExtensionInstaller automatiquement l’extension Claude Code IDE lors de l’exécution à partir d’un terminal VS Code. Par défaut : true. Apparaît dans /config comme Auto-install IDE extension lors de l’exécution dans un terminal VS Code ou JetBrains. Vous pouvez également définir la variable d’environnement CLAUDE_CODE_IDE_SKIP_AUTO_INSTALLfalse
autoScrollEnabledDans le rendu fullscreen, suivre la nouvelle sortie vers le bas de la conversation. Par défaut : true. Apparaît dans /config comme Auto-scroll. Les invites de permission font toujours défiler dans la vue quand ceci est désactivéfalse
editorModeMode de liaison de touches pour l’invite d’entrée : "normal" ou "vim". Par défaut : "normal". Apparaît dans /config comme Editor mode"vim"
externalEditorContextAjouter la réponse précédente de Claude comme contexte commenté avec # quand vous ouvrez l’éditeur externe avec Ctrl+G. Par défaut : false. Apparaît dans /config comme Show last response in external editortrue
showTurnDurationAfficher les messages de durée de tour après les réponses, par exemple « Cooked for 1m 6s ». Par défaut : true. Apparaît dans /config comme Show turn durationfalse
terminalProgressBarEnabledAfficher la barre de progression du terminal dans les terminaux supportés : ConEmu, Ghostty 1.2.0+, et iTerm2 3.6.6+. Par défaut : true. Apparaît dans /config comme Terminal progress barfalse
teammateModeComment les coéquipiers de l’équipe d’agents s’affichent : auto (choisit les volets divisés dans tmux ou iTerm2, en processus sinon), in-process, ou tmux. Voir configurer un mode d’affichage"in-process"

Paramètres de worktree

Configurez comment --worktree crée et gère les git worktrees. Utilisez ces paramètres pour réduire l’utilisation du disque et le temps de démarrage dans les grands monorepos.
CléDescriptionExemple
worktree.symlinkDirectoriesRépertoires à créer en lien symbolique à partir du référentiel principal dans chaque worktree pour éviter de dupliquer les grands répertoires sur le disque. Aucun répertoire n’est créé en lien symbolique par défaut["node_modules", ".cache"]
worktree.sparsePathsRépertoires à extraire dans chaque worktree via git sparse-checkout (mode cone). Seuls les chemins listés sont écrits sur le disque, ce qui est plus rapide dans les grands monorepos["packages/my-app", "shared/utils"]
Pour copier les fichiers ignorés par git comme .env dans les nouveaux worktrees, utilisez un fichier .worktreeinclude dans la racine de votre projet à la place d’un paramètre.

Paramètres de permission

ClésDescriptionExemple
allowTableau de règles de permission pour autoriser l’utilisation d’outils. Voir Syntaxe de règle de permission ci-dessous pour les détails de correspondance de modèle[ "Bash(git diff *)" ]
askTableau de règles de permission pour demander une confirmation lors de l’utilisation d’outils. Voir Syntaxe de règle de permission ci-dessous[ "Bash(git push *)" ]
denyTableau de règles de permission pour refuser l’utilisation d’outils. Utilisez ceci pour exclure les fichiers sensibles de l’accès de Claude Code. Voir Syntaxe de règle de permission et Limitations de permission Bash[ "WebFetch", "Bash(curl *)", "Read(./.env)", "Read(./secrets/**)" ]
additionalDirectoriesRépertoires de travail supplémentaires pour l’accès aux fichiers. La plupart de la configuration .claude/ n’est pas découverte à partir de ces répertoires[ "../docs/" ]
defaultModeMode de permission par défaut lors de l’ouverture de Claude Code. Valeurs valides : default, acceptEdits, plan, auto, dontAsk, bypassPermissions. L’indicateur CLI --permission-mode remplace ce paramètre pour une seule session"acceptEdits"
disableBypassPermissionsModeDéfinir à "disable" pour empêcher l’activation du mode bypassPermissions. Ceci désactive l’indicateur de ligne de commande --dangerously-skip-permissions. Généralement placé dans les paramètres gérés pour appliquer la politique organisationnelle, mais fonctionne à partir de n’importe quelle portée"disable"
skipDangerousModePermissionPromptIgnorer l’invite de confirmation affichée avant d’entrer en mode bypass permissions via --dangerously-skip-permissions ou defaultMode: "bypassPermissions". Ignoré quand défini dans les paramètres de projet (.claude/settings.json) pour empêcher les référentiels non fiables d’auto-contourner l’invitetrue

Syntaxe de règle de permission

Les règles de permission suivent le format Tool ou Tool(specifier). Les règles sont évaluées dans l’ordre : d’abord les règles de refus, puis de demande, puis d’autorisation. La première règle correspondante gagne. Exemples rapides :
RègleEffet
BashCorrespond à toutes les commandes Bash
Bash(npm run *)Correspond aux commandes commençant par npm run
Read(./.env)Correspond à la lecture du fichier .env
WebFetch(domain:example.com)Correspond aux demandes de récupération vers example.com
Pour la référence complète de la syntaxe des règles, y compris le comportement des caractères génériques, les modèles spécifiques aux outils pour Read, Edit, WebFetch, MCP, et Agent, et les limitations de sécurité des modèles Bash, voir Syntaxe de règle de permission.

Paramètres de sandbox

Configurez le comportement avancé du sandboxing. Le sandboxing isole les commandes bash de votre système de fichiers et réseau. Voir Sandboxing pour plus de détails.
ClésDescriptionExemple
enabledActiver le sandboxing bash (macOS, Linux, et WSL2). Par défaut : falsetrue
failIfUnavailableQuitter avec une erreur au démarrage si sandbox.enabled est true mais que le sandbox ne peut pas démarrer (dépendances manquantes ou plateforme non supportée). Quand false (par défaut), un avertissement est affiché et les commandes s’exécutent sans sandbox. Destiné aux déploiements de paramètres gérés qui nécessitent le sandboxing comme une porte duretrue
autoAllowBashIfSandboxedApprouver automatiquement les commandes bash quand sandboxées. Par défaut : truetrue
excludedCommandsCommandes qui doivent s’exécuter en dehors du sandbox["docker *"]
allowUnsandboxedCommandsAutoriser les commandes à s’exécuter en dehors du sandbox via le paramètre dangerouslyDisableSandbox. Quand défini à false, l’échappatoire dangerouslyDisableSandbox est complètement désactivée et toutes les commandes doivent s’exécuter en sandbox (ou être dans excludedCommands). Utile pour les politiques d’entreprise qui nécessitent un sandboxing strict. Par défaut : truefalse
filesystem.allowWriteChemins supplémentaires où les commandes sandboxées peuvent écrire. Les tableaux sont fusionnés dans toutes les portées de paramètres : les chemins utilisateur, projet et gérés sont combinés, non remplacés. Également fusionnés avec les chemins des règles de permission Edit(...) allow. Voir préfixes de chemin sandbox ci-dessous.["/tmp/build", "~/.kube"]
filesystem.denyWriteChemins où les commandes sandboxées ne peuvent pas écrire. Les tableaux sont fusionnés dans toutes les portées de paramètres. Également fusionnés avec les chemins des règles de permission Edit(...) deny.["/etc", "/usr/local/bin"]
filesystem.denyReadChemins où les commandes sandboxées ne peuvent pas lire. Les tableaux sont fusionnés dans toutes les portées de paramètres. Également fusionnés avec les chemins des règles de permission Read(...) deny.["~/.aws/credentials"]
filesystem.allowReadChemins à réautoriser pour la lecture dans les régions denyRead. A la priorité sur denyRead. Les tableaux sont fusionnés dans toutes les portées de paramètres. Utilisez ceci pour créer des modèles d’accès en lecture spécifiques à l’espace de travail.["."]
filesystem.allowManagedReadPathsOnly(Paramètres gérés uniquement) Seuls les chemins allowRead à partir des paramètres gérés sont respectés. denyRead fusionne toujours à partir de toutes les sources. Par défaut : falsetrue
network.allowUnixSockets(macOS uniquement) Chemins de socket Unix accessibles dans le sandbox. Ignoré sur Linux et WSL2, où le filtre seccomp ne peut pas inspecter les chemins de socket ; utilisez allowAllUnixSockets à la place.["~/.ssh/agent-socket"]
network.allowAllUnixSocketsAutoriser toutes les connexions de socket Unix dans le sandbox. Sur Linux et WSL2, c’est le seul moyen de permettre les sockets Unix, car il ignore le filtre seccomp qui bloque autrement les appels socket(AF_UNIX, ...). Par défaut : falsetrue
network.allowLocalBindingAutoriser la liaison aux ports localhost (macOS uniquement). Par défaut : falsetrue
network.allowMachLookupNoms de service XPC/Mach supplémentaires que le sandbox peut rechercher (macOS uniquement). Supporte un seul * de fin pour la correspondance de préfixe. Nécessaire pour les outils qui communiquent via XPC tels que le simulateur iOS ou Playwright.["com.apple.coresimulator.*"]
network.allowedDomainsTableau de domaines à autoriser pour le trafic réseau sortant. Supporte les caractères génériques (par exemple, *.example.com).["github.com", "*.npmjs.org"]
network.deniedDomainsTableau de domaines à bloquer pour le trafic réseau sortant. Supporte la même syntaxe de caractère générique que allowedDomains. A la priorité sur allowedDomains quand les deux correspondent. Fusionné à partir de toutes les sources de paramètres indépendamment de allowManagedDomainsOnly.["sensitive.cloud.example.com"]
network.allowManagedDomainsOnly(Paramètres gérés uniquement) Seul allowedDomains et les règles allow WebFetch(domain:...) à partir des paramètres gérés sont respectés. Les domaines à partir des paramètres utilisateur, projet et locaux sont ignorés. Les domaines non autorisés sont bloqués automatiquement sans inviter l’utilisateur. Les domaines refusés sont toujours respectés à partir de toutes les sources. Par défaut : falsetrue
network.httpProxyPortPort du proxy HTTP utilisé si vous souhaitez apporter votre propre proxy. S’il n’est pas spécifié, Claude exécutera son propre proxy.8080
network.socksProxyPortPort du proxy SOCKS5 utilisé si vous souhaitez apporter votre propre proxy. S’il n’est pas spécifié, Claude exécutera son propre proxy.8081
enableWeakerNestedSandboxActiver un sandbox plus faible pour les environnements Docker non privilégiés (Linux et WSL2 uniquement). Réduit la sécurité. Par défaut : falsetrue
enableWeakerNetworkIsolation(macOS uniquement) Autoriser l’accès au service de confiance TLS du système (com.apple.trustd.agent) dans le sandbox. Requis pour que les outils basés sur Go comme gh, gcloud, et terraform vérifient les certificats TLS lors de l’utilisation de httpProxyPort avec un proxy MITM et une CA personnalisée. Réduit la sécurité en ouvrant un chemin potentiel d’exfiltration de données. Par défaut : falsetrue

Préfixes de chemin sandbox

Les chemins dans filesystem.allowWrite, filesystem.denyWrite, filesystem.denyRead, et filesystem.allowRead supportent ces préfixes :
PréfixeSignificationExemple
/Chemin absolu à partir de la racine du système de fichiers/tmp/build reste /tmp/build
~/Relatif au répertoire personnel~/.kube devient $HOME/.kube
./ ou pas de préfixeRelatif à la racine du projet pour les paramètres de projet, ou à ~/.claude pour les paramètres utilisateur./output dans .claude/settings.json se résout en <project-root>/output
Le préfixe plus ancien //path pour les chemins absolus fonctionne toujours. Si vous aviez précédemment utilisé /path en s’attendant à une résolution relative au projet, passez à ./path. Cette syntaxe diffère des règles de permission Read et Edit, qui utilisent //path pour absolu et /path pour relatif au projet. Les chemins du système de fichiers sandbox utilisent les conventions standard : /tmp/build est un chemin absolu. Exemple de configuration :
{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "excludedCommands": ["docker *"],
    "filesystem": {
      "allowWrite": ["/tmp/build", "~/.kube"],
      "denyRead": ["~/.aws/credentials"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org", "registry.yarnpkg.com"],
      "deniedDomains": ["uploads.github.com"],
      "allowUnixSockets": [
        "/var/run/docker.sock"
      ],
      "allowLocalBinding": true
    }
  }
}
Les restrictions de système de fichiers et réseau peuvent être configurées de deux façons qui sont fusionnées ensemble :
  • Paramètres sandbox.filesystem (affichés ci-dessus) : Contrôlez les chemins à la limite du sandbox au niveau du système d’exploitation. Ces restrictions s’appliquent à toutes les commandes de sous-processus (par exemple, kubectl, terraform, npm), pas seulement aux outils de fichier de Claude.
  • Règles de permission : Utilisez les règles allow/deny Edit pour contrôler l’accès à l’outil de fichier de Claude, les règles deny Read pour bloquer les lectures, et les règles allow/deny WebFetch pour contrôler les domaines réseau. Les chemins de ces règles sont également fusionnés dans la configuration du sandbox.

Paramètres d’attribution

Claude Code ajoute l’attribution aux commits git et aux pull requests. Ceux-ci sont configurés séparément :
  • Les commits utilisent les trailers git (comme Co-Authored-By) par défaut, qui peuvent être personnalisés ou désactivés
  • Les descriptions de pull request sont du texte brut
ClésDescription
commitAttribution pour les commits git, y compris tous les trailers. La chaîne vide masque l’attribution de commit
prAttribution pour les descriptions de pull request. La chaîne vide masque l’attribution de pull request
Attribution de commit par défaut :
🤖 Generated with [Claude Code](https://claude.com/claude-code)

   Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Attribution de pull request par défaut :
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Exemple :
{
  "attribution": {
    "commit": "Generated with AI\n\nCo-Authored-By: AI <ai@example.com>",
    "pr": ""
  }
}
Le paramètre attribution a la priorité sur le paramètre déprécié includeCoAuthoredBy. Pour masquer toute attribution, définissez commit et pr à des chaînes vides.

Paramètres de suggestion de fichier

Configurez une commande personnalisée pour l’autocomplétion de chemin de fichier @. La suggestion de fichier intégrée utilise la traversée rapide du système de fichiers, mais les grands monorepos peuvent bénéficier d’une indexation spécifique au projet telle qu’un index de fichier pré-construit ou un outillage personnalisé.
{
  "fileSuggestion": {
    "type": "command",
    "command": "~/.claude/file-suggestion.sh"
  }
}
La commande s’exécute avec les mêmes variables d’environnement que les hooks, y compris CLAUDE_PROJECT_DIR. Elle reçoit du JSON via stdin avec un champ query :
{"query": "src/comp"}
Générez les chemins de fichier séparés par des sauts de ligne vers stdout (actuellement limité à 15) :
src/components/Button.tsx
src/components/Modal.tsx
src/components/Form.tsx
Exemple :
#!/bin/bash
query=$(cat | jq -r '.query')
your-repo-file-index --query "$query" | head -20

Configuration des hooks

Ces paramètres contrôlent quels hooks sont autorisés à s’exécuter et ce que les hooks HTTP peuvent accéder. Le paramètre allowManagedHooksOnly ne peut être configuré que dans les paramètres gérés. Les listes blanches d’URL et de variables d’environnement peuvent être définies à n’importe quel niveau de paramètres et fusionnent entre les sources. Comportement quand allowManagedHooksOnly est true :
  • Les hooks gérés et les hooks SDK sont chargés
  • Les hooks des plugins force-activés dans les paramètres gérés enabledPlugins sont chargés. Cela permet aux administrateurs de distribuer des hooks vérifiés via une marketplace organisationnelle tout en bloquant tout le reste. La confiance est accordée par l’ID complet plugin@marketplace, donc un plugin avec le même nom d’une marketplace différente reste bloqué
  • Les hooks utilisateur, projet et tous les autres hooks de plugin sont bloqués
Restreindre les URL des hooks HTTP : Limitez les URL que les hooks HTTP peuvent cibler. Supporte * comme caractère générique pour la correspondance. Quand le tableau est défini, les hooks HTTP ciblant des URL non correspondantes sont silencieusement bloqués.
{
  "allowedHttpHookUrls": ["https://hooks.example.com/*", "http://localhost:*"]
}
Restreindre les variables d’environnement des hooks HTTP : Limitez les noms de variables d’environnement que les hooks HTTP peuvent interpoler dans les valeurs d’en-tête. Le allowedEnvVars effectif de chaque hook est l’intersection de sa propre liste et ce paramètre.
{
  "httpHookAllowedEnvVars": ["MY_TOKEN", "HOOK_SECRET"]
}

Précédence des paramètres

Les paramètres s’appliquent dans l’ordre de précédence. Du plus élevé au plus bas :
  1. Paramètres gérés (gérés par le serveur, politiques MDM/au niveau du système d’exploitation, ou paramètres gérés)
    • Politiques déployées par l’IT via la livraison par serveur, les profils de configuration MDM, les politiques de registre, ou les fichiers de paramètres gérés
    • Ne peuvent pas être contournés par aucun autre niveau, y compris les arguments de ligne de commande
    • Au sein du niveau géré, la précédence est : gérés par le serveur > politiques MDM/au niveau du système d’exploitation > fichiers (managed-settings.d/*.json + managed-settings.json) > registre HKCU (Windows uniquement). Une seule source gérée est utilisée ; les sources ne fusionnent pas entre les niveaux. Au sein du niveau basé sur fichier, les fichiers drop-in et le fichier de base sont fusionnés ensemble.
  2. Arguments de ligne de commande
    • Remplacements temporaires pour une session spécifique
  3. Paramètres de projet local (.claude/settings.local.json)
    • Paramètres personnels spécifiques au projet
  4. Paramètres de projet partagés (.claude/settings.json)
    • Paramètres de projet partagés par l’équipe dans le contrôle de source
  5. Paramètres utilisateur (~/.claude/settings.json)
    • Paramètres globaux personnels
Cette hiérarchie garantit que les politiques organisationnelles sont toujours appliquées tout en permettant aux équipes et aux individus de personnaliser leur expérience. La même précédence s’applique que vous exécutiez Claude Code à partir de la CLI, de l’extension VS Code, ou d’un IDE JetBrains. Par exemple, si vos paramètres utilisateur autorisent Bash(npm run *) mais que les paramètres partagés d’un projet le refusent, le paramètre de projet a la priorité et la commande est bloquée.
Les paramètres de tableau fusionnent entre les portées. Quand le même paramètre avec valeur de tableau (tel que sandbox.filesystem.allowWrite ou permissions.allow) apparaît dans plusieurs portées, les tableaux sont concaténés et dédupliqués, non remplacés. Cela signifie que les portées de priorité inférieure peuvent ajouter des entrées sans remplacer celles définies par les portées de priorité supérieure, et vice versa. Par exemple, si les paramètres gérés définissent allowWrite à ["/opt/company-tools"] et qu’un utilisateur ajoute ["~/.kube"], les deux chemins sont inclus dans la configuration finale.

Vérifier les paramètres actifs

Exécutez /status dans Claude Code pour voir quelles sources de paramètres sont actives et d’où elles proviennent. La sortie affiche chaque couche de configuration (gérée, utilisateur, projet) ainsi que son origine, telle que Enterprise managed settings (remote), Enterprise managed settings (plist), Enterprise managed settings (HKLM), Enterprise managed settings (HKCU), ou Enterprise managed settings (file). Si un fichier de paramètres contient des erreurs, /status signale le problème pour que vous puissiez le corriger.

Points clés du système de configuration

  • Fichiers de mémoire (CLAUDE.md) : Contiennent les instructions et le contexte que Claude charge au démarrage
  • Fichiers de paramètres (JSON) : Configurez les permissions, les variables d’environnement, et le comportement des outils
  • Skills : Invites personnalisées qui peuvent être invoquées avec /skill-name ou chargées automatiquement par Claude
  • MCP servers : Étendez Claude Code avec des outils et des intégrations supplémentaires
  • Précédence : Les configurations de niveau supérieur (Managed) remplacent celles de niveau inférieur (User/Project)
  • Héritage : Les paramètres sont fusionnés, avec les paramètres plus spécifiques s’ajoutant à ou remplaçant les paramètres plus larges

Invite système

L’invite système interne de Claude Code n’est pas publiée. Pour ajouter des instructions personnalisées, utilisez les fichiers CLAUDE.md ou l’indicateur --append-system-prompt.

Exclure les fichiers sensibles

Pour empêcher Claude Code d’accéder aux fichiers contenant des informations sensibles comme les clés API, les secrets, et les fichiers d’environnement, utilisez le paramètre permissions.deny dans votre fichier .claude/settings.json :
{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Read(./build)"
    ]
  }
}
Ceci remplace la configuration dépréciée ignorePatterns. Les fichiers correspondant à ces modèles sont exclus de la découverte de fichiers et des résultats de recherche, et les opérations de lecture sur ces fichiers sont refusées.

Configuration des subagents

Claude Code supporte les subagents IA personnalisés qui peuvent être configurés aux niveaux utilisateur et projet. Ces subagents sont stockés en tant que fichiers Markdown avec du frontmatter YAML :
  • Subagents utilisateur : ~/.claude/agents/ - Disponibles dans tous vos projets
  • Subagents de projet : .claude/agents/ - Spécifiques à votre projet et peuvent être partagés avec votre équipe
Les fichiers de subagent définissent des assistants IA spécialisés avec des invites personnalisées et des permissions d’outils. En savoir plus sur la création et l’utilisation des subagents dans la documentation des subagents.

Configuration des plugins

Claude Code supporte un système de plugins qui vous permet d’étendre les fonctionnalités avec des skills, des agents, des hooks, et des MCP servers. Les plugins sont distribués via des marketplaces et peuvent être configurés aux niveaux utilisateur et référentiel.

Paramètres des plugins

Paramètres liés aux plugins dans settings.json :
{
  "enabledPlugins": {
    "formatter@acme-tools": true,
    "deployer@acme-tools": true,
    "analyzer@security-plugins": false
  },
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": "github",
      "repo": "acme-corp/claude-plugins"
    }
  }
}

enabledPlugins

Contrôle quels plugins sont activés. Format : "plugin-name@marketplace-name": true/false Portées :
  • Paramètres utilisateur (~/.claude/settings.json) : Préférences personnelles de plugin
  • Paramètres de projet (.claude/settings.json) : Plugins spécifiques au projet partagés avec l’équipe
  • Paramètres locaux (.claude/settings.local.json) : Remplacements par machine (non commités)
  • Paramètres gérés (managed-settings.json) : Remplacements de politique au niveau de l’organisation qui bloquent l’installation à toutes les portées et masquent le plugin de la marketplace
Exemple :
{
  "enabledPlugins": {
    "code-formatter@team-tools": true,
    "deployment-tools@team-tools": true,
    "experimental-features@personal": false
  }
}

extraKnownMarketplaces

Définit les marketplaces supplémentaires qui doivent être mises à disposition pour le référentiel. Généralement utilisé dans les paramètres au niveau du référentiel pour s’assurer que les membres de l’équipe ont accès aux sources de plugins requises. Quand un référentiel inclut extraKnownMarketplaces :
  1. Les membres de l’équipe sont invités à installer la marketplace quand ils font confiance au dossier
  2. Les membres de l’équipe sont ensuite invités à installer les plugins de cette marketplace
  3. Les utilisateurs peuvent ignorer les marketplaces ou plugins indésirables (stockés dans les paramètres utilisateur)
  4. L’installation respecte les limites de confiance et nécessite un consentement explicite
Exemple :
{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": {
        "source": "github",
        "repo": "acme-corp/claude-plugins"
      }
    },
    "security-plugins": {
      "source": {
        "source": "git",
        "url": "https://git.example.com/security/plugins.git"
      }
    }
  }
}
Types de source de marketplace :
  • github : Référentiel GitHub (utilise repo)
  • git : N’importe quelle URL git (utilise url)
  • directory : Chemin du système de fichiers local (utilise path, pour le développement uniquement)
  • hostPattern : Modèle regex pour correspondre aux hôtes de marketplace (utilise hostPattern)
  • settings : marketplace en ligne déclarée directement dans settings.json sans référentiel hébergé séparé (utilise name et plugins)
Utilisez source: 'settings' pour déclarer un petit ensemble de plugins en ligne sans configurer un référentiel de marketplace hébergé. Les plugins listés ici doivent référencer des sources externes telles que GitHub ou npm. Vous devez toujours activer chaque plugin séparément dans enabledPlugins.
{
  "extraKnownMarketplaces": {
    "team-tools": {
      "source": {
        "source": "settings",
        "name": "team-tools",
        "plugins": [
          {
            "name": "code-formatter",
            "source": {
              "source": "github",
              "repo": "acme-corp/code-formatter"
            }
          }
        ]
      }
    }
  }
}

strictKnownMarketplaces

Paramètres gérés uniquement : Contrôle quelles marketplaces de plugins les utilisateurs sont autorisés à ajouter et installer des plugins à partir de. Ce paramètre ne peut être configuré que dans les paramètres gérés et fournit aux administrateurs un contrôle strict sur les sources de marketplace. Emplacements des fichiers de paramètres gérés :
  • macOS : /Library/Application Support/ClaudeCode/managed-settings.json
  • Linux et WSL : /etc/claude-code/managed-settings.json
  • Windows : C:\Program Files\ClaudeCode\managed-settings.json
Caractéristiques clés :
  • Disponible uniquement dans les paramètres gérés (managed-settings.json)
  • Ne peut pas être contourné par les paramètres utilisateur ou projet (précédence la plus élevée)
  • Appliqué AVANT les opérations de réseau/système de fichiers (les sources bloquées ne s’exécutent jamais)
  • Utilise la correspondance exacte pour les spécifications de source (y compris ref, path pour les sources git), sauf hostPattern, qui utilise la correspondance regex
Comportement de la liste blanche :
  • undefined (par défaut) : Pas de restrictions - les utilisateurs peuvent ajouter n’importe quelle marketplace
  • Tableau vide [] : Verrouillage complet - les utilisateurs ne peuvent pas ajouter de nouvelles marketplaces
  • Liste de sources : Les utilisateurs ne peuvent ajouter que les marketplaces qui correspondent exactement
Tous les types de source supportés : La liste blanche supporte plusieurs types de source de marketplace. La plupart des sources utilisent la correspondance exacte, tandis que hostPattern utilise la correspondance regex par rapport à l’hôte de la marketplace.
  1. Référentiels GitHub :
{ "source": "github", "repo": "acme-corp/approved-plugins" }
{ "source": "github", "repo": "acme-corp/security-tools", "ref": "v2.0" }
{ "source": "github", "repo": "acme-corp/plugins", "ref": "main", "path": "marketplace" }
Champs : repo (requis), ref (optionnel : branche/tag/SHA), path (optionnel : sous-répertoire)
  1. Référentiels Git :
{ "source": "git", "url": "https://gitlab.example.com/tools/plugins.git" }
{ "source": "git", "url": "https://bitbucket.org/acme-corp/plugins.git", "ref": "production" }
{ "source": "git", "url": "ssh://git@git.example.com/plugins.git", "ref": "v3.1", "path": "approved" }
Champs : url (requis), ref (optionnel : branche/tag/SHA), path (optionnel : sous-répertoire)
  1. Marketplaces basées sur URL :
{ "source": "url", "url": "https://plugins.example.com/marketplace.json" }
{ "source": "url", "url": "https://cdn.example.com/marketplace.json", "headers": { "Authorization": "Bearer ${TOKEN}" } }
Champs : url (requis), headers (optionnel : en-têtes HTTP pour l’accès authentifié)
Les marketplaces basées sur URL téléchargent uniquement le fichier marketplace.json. Elles ne téléchargent pas les fichiers de plugin à partir du serveur. Les plugins dans les marketplaces basées sur URL doivent utiliser des sources externes (URLs GitHub, npm, ou git) plutôt que des chemins relatifs. Pour les plugins avec des chemins relatifs, utilisez une marketplace basée sur Git à la place. Voir Dépannage pour plus de détails.
  1. Packages NPM :
{ "source": "npm", "package": "@acme-corp/claude-plugins" }
{ "source": "npm", "package": "@acme-corp/approved-marketplace" }
Champs : package (requis, supporte les packages scoped)
  1. Chemins de fichier :
{ "source": "file", "path": "/usr/local/share/claude/acme-marketplace.json" }
{ "source": "file", "path": "/opt/acme-corp/plugins/marketplace.json" }
Champs : path (requis : chemin absolu vers le fichier marketplace.json)
  1. Chemins de répertoire :
{ "source": "directory", "path": "/usr/local/share/claude/acme-plugins" }
{ "source": "directory", "path": "/opt/acme-corp/approved-marketplaces" }
Champs : path (requis : chemin absolu vers le répertoire contenant .claude-plugin/marketplace.json)
  1. Correspondance de modèle d’hôte :
{ "source": "hostPattern", "hostPattern": "^github\\.example\\.com$" }
{ "source": "hostPattern", "hostPattern": "^gitlab\\.internal\\.example\\.com$" }
Champs : hostPattern (requis : modèle regex pour correspondre à l’hôte de la marketplace) Utilisez la correspondance de modèle d’hôte quand vous voulez autoriser toutes les marketplaces d’un hôte spécifique sans énumérer chaque référentiel individuellement. Ceci est utile pour les organisations avec des serveurs GitHub Enterprise ou GitLab internes où les développeurs créent leurs propres marketplaces. Extraction d’hôte par type de source :
  • github : correspond toujours à github.com
  • git : extrait le nom d’hôte de l’URL (supporte les formats HTTPS et SSH)
  • url : extrait le nom d’hôte de l’URL
  • npm, file, directory : non supporté pour la correspondance de modèle d’hôte
Exemples de configuration : Exemple : autoriser uniquement les marketplaces spécifiques :
{
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "acme-corp/approved-plugins"
    },
    {
      "source": "github",
      "repo": "acme-corp/security-tools",
      "ref": "v2.0"
    },
    {
      "source": "url",
      "url": "https://plugins.example.com/marketplace.json"
    },
    {
      "source": "npm",
      "package": "@acme-corp/compliance-plugins"
    }
  ]
}
Exemple - Désactiver tous les ajouts de marketplace :
{
  "strictKnownMarketplaces": []
}
Exemple : autoriser toutes les marketplaces d’un serveur git interne :
{
  "strictKnownMarketplaces": [
    {
      "source": "hostPattern",
      "hostPattern": "^github\\.example\\.com$"
    }
  ]
}
Exigences de correspondance exacte : Les sources de marketplace doivent correspondre exactement pour qu’un ajout d’utilisateur soit autorisé. Pour les sources basées sur git (github et git), cela inclut tous les champs optionnels :
  • Le repo ou url doit correspondre exactement
  • Le champ ref doit correspondre exactement (ou les deux être non définis)
  • Le champ path doit correspondre exactement (ou les deux être non définis)
Exemples de sources qui NE correspondent PAS :
// Ce sont des sources DIFFÉRENTES :
{ "source": "github", "repo": "acme-corp/plugins" }
{ "source": "github", "repo": "acme-corp/plugins", "ref": "main" }

// Ce sont aussi DIFFÉRENTES :
{ "source": "github", "repo": "acme-corp/plugins", "path": "marketplace" }
{ "source": "github", "repo": "acme-corp/plugins" }
Comparaison avec extraKnownMarketplaces :
AspectstrictKnownMarketplacesextraKnownMarketplaces
ObjectifApplication de la politique organisationnelleCommodité de l’équipe
Fichier de paramètresmanaged-settings.json uniquementN’importe quel fichier de paramètres
ComportementBloque les ajouts non autorisésInstalle automatiquement les marketplaces manquantes
Quand appliquéAvant les opérations de réseau/système de fichiersAprès l’invite de confiance de l’utilisateur
Peut être contournéNon (précédence la plus élevée)Oui (par les paramètres de précédence supérieure)
Format de sourceObjet de source directMarketplace nommée avec source imbriquée
Cas d’usageConformité, restrictions de sécuritéIntégration, standardisation
Différence de format : strictKnownMarketplaces utilise des objets de source directs :
{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/plugins" }
  ]
}
extraKnownMarketplaces nécessite des marketplaces nommées :
{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/plugins" }
    }
  }
}
Utiliser les deux ensemble : strictKnownMarketplaces est une porte de politique : elle contrôle ce que les utilisateurs peuvent ajouter mais n’enregistre aucune marketplace. Pour à la fois restreindre et pré-enregistrer une marketplace pour tous les utilisateurs, définissez les deux dans managed-settings.json :
{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "acme-corp/plugins" }
  ],
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "github", "repo": "acme-corp/plugins" }
    }
  }
}
Avec uniquement strictKnownMarketplaces défini, les utilisateurs peuvent toujours ajouter la marketplace autorisée manuellement via /plugin marketplace add, mais elle n’est pas disponible automatiquement. Notes importantes :
  • Les restrictions sont vérifiées AVANT toute demande réseau ou opération de système de fichiers
  • Quand bloquée, les utilisateurs voient des messages d’erreur clairs indiquant que la source est bloquée par la politique gérée
  • La restriction s’applique à l’ajout de marketplace et à l’installation, la mise à jour, l’actualisation et la mise à jour automatique de plugins. Une marketplace ajoutée avant que la politique soit définie ne peut pas être utilisée pour installer ou mettre à jour des plugins une fois que sa source ne correspond plus à la liste blanche
  • Les paramètres gérés ont la précédence la plus élevée et ne peuvent pas être contournés
Voir Restrictions de marketplace gérées pour la documentation destinée aux utilisateurs.

Gérer les plugins

Utilisez la commande /plugin pour gérer les plugins de manière interactive :
  • Parcourir les plugins disponibles à partir des marketplaces
  • Installer/désinstaller les plugins
  • Activer/désactiver les plugins
  • Afficher les détails du plugin (skills, agents, hooks fournis)
  • Ajouter/supprimer les marketplaces
En savoir plus sur le système de plugins dans la documentation des plugins.

Variables d’environnement

Les variables d’environnement vous permettent de contrôler le comportement de Claude Code sans éditer les fichiers de paramètres. N’importe quelle variable peut également être configurée dans settings.json sous la clé env pour l’appliquer à chaque session ou la déployer à votre équipe. Voir la référence des variables d’environnement pour la liste complète.

Outils disponibles pour Claude

Claude Code a accès à un ensemble d’outils pour lire, éditer, rechercher, exécuter des commandes, et orchestrer les subagents. Les noms d’outils sont les chaînes exactes que vous utilisez dans les règles de permission et les correspondances de hooks. Voir la référence des outils pour la liste complète et les détails du comportement de l’outil Bash.

Voir aussi

  • Permissions : système de permissions, syntaxe des règles, modèles spécifiques aux outils, et politiques gérées
  • Authentification : configurer l’accès utilisateur à Claude Code
  • Déboguer votre configuration : diagnostiquer pourquoi un paramètre, un hook, ou un serveur MCP ne prend pas effet
  • Dépannage : problèmes d’installation, d’authentification, et de plateforme