/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ée | Emplacement | Qui est affecté | Partagé avec l’équipe ? |
|---|---|---|---|
| Managed | Paramètres gérés par le serveur, plist / registre, ou managed-settings.json au niveau système | Tous les utilisateurs de la machine | Oui (déployé par l’IT) |
| User | Répertoire ~/.claude/ | Vous, dans tous les projets | Non |
| Project | .claude/ dans le référentiel | Tous les collaborateurs de ce référentiel | Oui (commité dans git) |
| Local | .claude/settings.local.json | Vous, dans ce référentiel uniquement | Non (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
- 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)
- 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
- 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é :- Managed (la plus élevée) - ne peut pas être contournée par quoi que ce soit
- Arguments de ligne de commande - remplacements de session temporaires
- Local - remplace les paramètres de projet et d’utilisateur
- Project - remplace les paramètres d’utilisateur
- User (la plus basse) - s’applique quand rien d’autre ne spécifie le paramètre
Ce qui utilise les portées
Les portées s’appliquent à de nombreuses fonctionnalités de Claude Code :| Fonctionnalité | Emplacement utilisateur | Emplacement projet | Emplacement 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.md | CLAUDE.md ou .claude/CLAUDE.md | CLAUDE.local.md |
Fichiers de paramètres
Le fichiersettings.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.jsonet s’appliquent à tous les projets. -
Les paramètres de projet sont enregistrés dans votre répertoire de projet :
.claude/settings.jsonpour les paramètres qui sont vérifiés dans le contrôle de source et partagés avec votre équipe.claude/settings.local.jsonpour 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.jsonquand 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ètentmanaged-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\ClaudeCodeavec une valeurSettings(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)
- macOS : domaine de préférences gérées
-
Basé sur fichier :
managed-settings.jsonetmanaged-mcp.jsondéployés dans les répertoires système :- macOS :
/Library/Application Support/ClaudeCode/ - Linux et WSL :
/etc/claude-code/ - Windows :
C:\Program Files\ClaudeCode\
managed-settings.d/dans le même répertoire système à côté demanaged-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.jsonest fusionné en premier comme base, puis tous les fichiers*.jsondans 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 exemple10-telemetry.jsonet20-security.json. - macOS :
Les déploiements gérés peuvent également restreindre les ajouts de marketplace de plugins en utilisantstrictKnownMarketplaces. 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 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é | Description | Exemple |
|---|---|---|
agent | Exé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" }] |
allowedHttpHookUrls | Liste 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/*"] |
allowedMcpServers | Quand 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 hooks | true |
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ée | true |
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 uniquement | true |
alwaysThinkingEnabled | Activer la réflexion étendue par défaut pour toutes les sessions. Généralement configuré via la commande /config plutôt que d’éditer directement | true |
apiKeyHelper | Script 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 |
attribution | Personnalisez l’attribution pour les commits git et les pull requests. Voir Paramètres d’attribution | {"commit": "🤖 Generated with Claude Code", "pr": ""} |
autoMemoryDirectory | Ré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" |
autoMode | Personnalisez 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"]} |
autoUpdatesChannel | Canal 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" |
availableModels | Restreindre 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"] |
awaySummaryEnabled | Afficher 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_SUMMARY | true |
awsAuthRefresh | Script personnalisé qui modifie le répertoire .aws (voir configuration avancée des identifiants) | aws sso login --profile myprofile |
awsCredentialExport | Script 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 à --channels | true |
cleanupPeriodDays | Les 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 |
companyAnnouncements | Annonce à 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"] |
defaultShell | Shell 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" |
deniedMcpServers | Quand 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" }] |
disableAllHooks | Désactiver tous les hooks et toute ligne d’état personnalisée | true |
disableAutoMode | Dé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" |
disableDeepLinkRegistration | Dé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" |
disabledMcpjsonServers | Liste des MCP servers spécifiques à partir des fichiers .mcp.json à rejeter | ["filesystem"] |
disableSkillShellExecution | Dé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 contourner | true |
effortLevel | Persister 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" |
enableAllProjectMcpServers | Approuver automatiquement tous les MCP servers définis dans les fichiers .mcp.json du projet | true |
enabledMcpjsonServers | Liste des MCP servers spécifiques à partir des fichiers .mcp.json à approuver | ["memory", "github"] |
env | Variables d’environnement qui seront appliquées à chaque session | {"FOO": "bar"} |
fastModePerSessionOptIn | Quand 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 session | true |
feedbackSurveyRate | Probabilité (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 pas | 0.05 |
fileSuggestion | Configurez un script personnalisé pour l’autocomplétion de fichier @. Voir Paramètres de suggestion de fichier | {"type": "command", "command": "~/.claude/file-suggestion.sh"} |
forceLoginMethod | Utilisez claudeai pour restreindre la connexion aux comptes Claude.ai, console pour restreindre la connexion aux comptes Claude Console (facturation d’utilisation d’API) | claudeai |
forceLoginOrgUUID | Exiger 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-closed | true |
hooks | Configurez des commandes personnalisées à exécuter lors d’événements du cycle de vie. Voir documentation des hooks pour le format | Voir hooks |
httpHookAllowedEnvVars | Liste 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"] |
includeCoAuthoredBy | Dé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 |
includeGitInstructions | Inclure 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éfinie | false |
language | Configurez 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" |
minimumVersion | Plancher 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" |
model | Remplacer le modèle par défaut à utiliser pour Claude Code | "claude-sonnet-4-6" |
modelOverrides | Mapper 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:..."} |
otelHeadersHelper | Script 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 |
outputStyle | Configurez un style de sortie pour ajuster l’invite système. Voir documentation des styles de sortie | "Explanatory" |
permissions | Voir le tableau ci-dessous pour la structure des permissions. | |
plansDirectory | Personnalisez 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" |
prefersReducedMotion | Réduire ou désactiver les animations de l’interface utilisateur (spinners, shimmer, effets flash) pour l’accessibilité | true |
respectGitignore | Contrô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 suggestions | false |
showClearContextOnPlanAccept | Afficher l’option « effacer le contexte » sur l’écran d’acceptation du plan. Par défaut : false. Définir à true pour restaurer l’option | true |
showThinkingSummaries | Afficher 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ètre | true |
skipWebFetchPreflight | Ignorer 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 blocage | true |
spinnerTipsEnabled | Afficher les conseils dans le spinner pendant que Claude travaille. Définir à false pour désactiver les conseils (par défaut : true) | false |
spinnerTipsOverride | Remplacer 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"] } |
spinnerVerbs | Personnalisez 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"]} |
sshConfigs | Connexions 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"}] |
statusLine | Configurez 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" }] |
tui | Moteur 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" |
useAutoModeDuringPlan | Si 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 |
viewMode | Mode d’affichage de transcript par défaut au démarrage : "default", "verbose", ou "focus". Remplace la sélection sticky /focus quand défini | "verbose" |
voice | Paramè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" } |
voiceEnabled | Alias hérité pour voice.enabled. Préférez l’objet voice | true |
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 natif | true |
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é | Description | Exemple |
|---|---|---|
autoConnectIde | Se 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 JetBrains | true |
autoInstallIdeExtension | Installer 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_INSTALL | false |
autoScrollEnabled | Dans 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 |
editorMode | Mode 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" |
externalEditorContext | Ajouter 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 editor | true |
showTurnDuration | Afficher 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 duration | false |
terminalProgressBarEnabled | Afficher 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 bar | false |
teammateMode | Comment 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é | Description | Exemple |
|---|---|---|
worktree.symlinkDirectories | Ré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.sparsePaths | Ré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"] |
.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és | Description | Exemple |
|---|---|---|
allow | Tableau 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 *)" ] |
ask | Tableau 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 *)" ] |
deny | Tableau 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/**)" ] |
additionalDirectories | Ré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/" ] |
defaultMode | Mode 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" |
disableBypassPermissionsMode | Dé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" |
skipDangerousModePermissionPrompt | Ignorer 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’invite | true |
Syntaxe de règle de permission
Les règles de permission suivent le formatTool 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ègle | Effet |
|---|---|
Bash | Correspond à 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 |
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és | Description | Exemple |
|---|---|---|
enabled | Activer le sandboxing bash (macOS, Linux, et WSL2). Par défaut : false | true |
failIfUnavailable | Quitter 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 dure | true |
autoAllowBashIfSandboxed | Approuver automatiquement les commandes bash quand sandboxées. Par défaut : true | true |
excludedCommands | Commandes qui doivent s’exécuter en dehors du sandbox | ["docker *"] |
allowUnsandboxedCommands | Autoriser 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 : true | false |
filesystem.allowWrite | Chemins 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.denyWrite | Chemins 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.denyRead | Chemins 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.allowRead | Chemins à 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 : false | true |
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.allowAllUnixSockets | Autoriser 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 : false | true |
network.allowLocalBinding | Autoriser la liaison aux ports localhost (macOS uniquement). Par défaut : false | true |
network.allowMachLookup | Noms 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.allowedDomains | Tableau 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.deniedDomains | Tableau 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 : false | true |
network.httpProxyPort | Port 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.socksProxyPort | Port 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 |
enableWeakerNestedSandbox | Activer un sandbox plus faible pour les environnements Docker non privilégiés (Linux et WSL2 uniquement). Réduit la sécurité. Par défaut : false | true |
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 : false | true |
Préfixes de chemin sandbox
Les chemins dansfilesystem.allowWrite, filesystem.denyWrite, filesystem.denyRead, et filesystem.allowRead supportent ces préfixes :
| Préfixe | Signification | Exemple |
|---|---|---|
/ | 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éfixe | Relatif à 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 |
//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 :
- 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
Editpour contrôler l’accès à l’outil de fichier de Claude, les règles denyReadpour bloquer les lectures, et les règles allow/denyWebFetchpour 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és | Description |
|---|---|
commit | Attribution pour les commits git, y compris tous les trailers. La chaîne vide masque l’attribution de commit |
pr | Attribution pour les descriptions de pull request. La chaîne vide masque l’attribution de pull request |
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é.
CLAUDE_PROJECT_DIR. Elle reçoit du JSON via stdin avec un champ query :
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ètreallowManagedHooksOnly 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
enabledPluginssont 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 completplugin@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
* 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.
allowedEnvVars effectif de chaque hook est l’intersection de sa propre liste et ce paramètre.
Précédence des paramètres
Les paramètres s’appliquent dans l’ordre de précédence. Du plus élevé au plus bas :-
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.
-
Arguments de ligne de commande
- Remplacements temporaires pour une session spécifique
-
Paramètres de projet local (
.claude/settings.local.json)- Paramètres personnels spécifiques au projet
-
Paramètres de projet partagés (
.claude/settings.json)- Paramètres de projet partagés par l’équipe dans le contrôle de source
-
Paramètres utilisateur (
~/.claude/settings.json)- Paramètres globaux personnels
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-nameou 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 fichiersCLAUDE.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ètrepermissions.deny dans votre fichier .claude/settings.json :
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
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 danssettings.json :
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
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 :
- Les membres de l’équipe sont invités à installer la marketplace quand ils font confiance au dossier
- Les membres de l’équipe sont ensuite invités à installer les plugins de cette marketplace
- Les utilisateurs peuvent ignorer les marketplaces ou plugins indésirables (stockés dans les paramètres utilisateur)
- L’installation respecte les limites de confiance et nécessite un consentement explicite
github: Référentiel GitHub (utiliserepo)git: N’importe quelle URL git (utiliseurl)directory: Chemin du système de fichiers local (utilisepath, pour le développement uniquement)hostPattern: Modèle regex pour correspondre aux hôtes de marketplace (utilisehostPattern)settings: marketplace en ligne déclarée directement dans settings.json sans référentiel hébergé séparé (utilisenameetplugins)
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.
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
- 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,pathpour les sources git), saufhostPattern, qui utilise la correspondance regex
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
hostPattern utilise la correspondance regex par rapport à l’hôte de la marketplace.
- Référentiels GitHub :
repo (requis), ref (optionnel : branche/tag/SHA), path (optionnel : sous-répertoire)
- Référentiels Git :
url (requis), ref (optionnel : branche/tag/SHA), path (optionnel : sous-répertoire)
- Marketplaces basées sur URL :
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.- Packages NPM :
package (requis, supporte les packages scoped)
- Chemins de fichier :
path (requis : chemin absolu vers le fichier marketplace.json)
- Chemins de répertoire :
path (requis : chemin absolu vers le répertoire contenant .claude-plugin/marketplace.json)
- Correspondance de modèle d’hôte :
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.comgit: extrait le nom d’hôte de l’URL (supporte les formats HTTPS et SSH)url: extrait le nom d’hôte de l’URLnpm,file,directory: non supporté pour la correspondance de modèle d’hôte
github et git), cela inclut tous les champs optionnels :
- Le
repoouurldoit correspondre exactement - Le champ
refdoit correspondre exactement (ou les deux être non définis) - Le champ
pathdoit correspondre exactement (ou les deux être non définis)
extraKnownMarketplaces :
| Aspect | strictKnownMarketplaces | extraKnownMarketplaces |
|---|---|---|
| Objectif | Application de la politique organisationnelle | Commodité de l’équipe |
| Fichier de paramètres | managed-settings.json uniquement | N’importe quel fichier de paramètres |
| Comportement | Bloque les ajouts non autorisés | Installe automatiquement les marketplaces manquantes |
| Quand appliqué | Avant les opérations de réseau/système de fichiers | Aprè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 source | Objet de source direct | Marketplace nommée avec source imbriquée |
| Cas d’usage | Conformité, restrictions de sécurité | Intégration, standardisation |
strictKnownMarketplaces utilise des objets de source directs :
extraKnownMarketplaces nécessite des marketplaces nommées :
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 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
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
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 danssettings.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