SpyBara
Go Premium

managed-settings.md 2026-09-28 22:59 UTC to 2026-09-29 13:59 UTC

This page contains 53 additions and 18 deletions.

2026
Sat 12 03:02 Mon 14 22:58 Fri 18 23:58 Tue 22 23:59 Thu 24 22:57 Fri 25 23:58 Mon 28 22:59 Tue 29 14:57

Déployer les paramètres gérés

Déployez les paramètres gérés sur la machine de chaque développeur : mécanismes de livraison par système d'exploitation, comment Claude Code combine les sources gérées, et comment vérifier l'application.

Les paramètres gérés sont les paramètres que votre organisation déploie sur la machine de chaque développeur. Claude Code les applique au-dessus de tous les autres niveaux, donc aucune valeur utilisateur, projet, locale ou --settings ne peut les remplacer, à l'exception de quelques exceptions sensibles à la sécurité où une valeur plus stricte d'un niveau inférieur compte toujours.

Cette page s'adresse à l'administrateur qui déploie les paramètres gérés ou qui débogue pourquoi l'un d'eux ne s'applique pas. Pour décider ce qu'il faut appliquer, commencez par le tableau Décider ce qu'il faut appliquer. Pour le chemin de la console claude.ai, consultez Paramètres gérés par le serveur. Pour savoir dans quel fichier les propres valeurs d'un développeur vont, consultez Paramètres.

Déployer un fichier de paramètres gérés

C'est le moyen le plus rapide de mettre une politique sur chaque machine : un fichier managed-settings.json. Si vous n'avez pas encore choisi comment livrer les paramètres gérés, ou si vos appareils sont sous MDM ou si les développeurs exécutent des sessions cloud, lisez d'abord Choisir un mécanisme de livraison.

1

Écrire managed-settings.json

Écrivez un managed-settings.json qui contient les clés que vous avez décidé d'appliquer, dans la même forme JSON que settings.json. Le tableau Décider ce qu'il faut appliquer énumère les clés derrière chaque contrôle, et chaque entrée dans la référence des paramètres indique si une source gérée peut la définir. Ce fichier bloque deux lectures de fichiers, désactive le mode de contournement, et fait que Claude Code ignore les règles de permission des fichiers utilisateur, projet et local et de --allowedTools :

{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./secrets/**)"
],
"disableBypassPermissionsMode": "disable"
},
"allowManagedPermissionRulesOnly": true
}

Pour un exemple plus complet qui montre la forme de plus de clés gérées, y compris la méthode de connexion, les modèles, les serveurs MCP et les places de marché, consultez Les paramètres gérés d'une organisation.

2

Placer le fichier sur chaque machine

Enregistrez le fichier sous le nom managed-settings.json dans le répertoire système du système d'exploitation, en utilisant les outils que vous utilisez déjà pour placer des fichiers sur votre parc :

  • 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
3

Confirmer que la politique a été appliquée

Sur une machine, exécutez /status dans Claude Code. La ligne Setting sources affiche Enterprise managed settings (file). Déployez sur le reste du parc après cela ; Vérifier qu'une politique est en vigueur couvre ce qu'il faut regarder quand la ligne est manquante.

Choisir un mécanisme de livraison

Le fichier dans les étapes ci-dessus est l'un des quatre moyens de mettre les paramètres gérés sur une machine. Chaque mécanisme porte les mêmes clés de politique qu'un fichier settings.json, donc la référence des paramètres s'applique à tous. Quelques clés sont liées à des sources particulières, et la ligne Scope de chaque entrée indique lesquelles :

Un fichier de paramètres gérés, un profil MDM, ou la console claude.ai applique une politique à tous ceux qu'il atteint. Pour donner à un groupe de développeurs une politique différente, déployez un fichier ou un profil différent à ce groupe ; la console claude.ai ne peut pas encore cibler un groupe, tandis qu'une passerelle d'applications Claude auto-hébergée livre les paramètres gérés par groupe IdP.

Quand plus d'un mécanisme livre une politique à la même machine, Claude Code utilise par défaut l'un et ignore les autres. Comment Claude Code combine les sources gérées donne l'ordre et l'opt-in qui s'applique à chaque source.

Les lignes MDM et fichier sont ensemble appelées paramètres gérés par le point de terminaison, car la politique est stockée sur l'appareil du développeur, par opposition à la ligne gérée par le serveur, où Claude Code la récupère.

Choisissez un mécanisme selon la façon dont vous gérez déjà les appareils, en utilisant le tableau ci-dessous.

Mécanisme Comment vous le livrez Quand Claude Code le lit Utilisez-le quand
Paramètres gérés par le serveur Dans la console d'administration claude.ai, ou sur une passerelle d'applications Claude auto-hébergée Récupérés au démarrage et interrogés toutes les heures ; consultez les modifications qui nécessitent une approbation Vous voulez un seul endroit pour changer la politique pour une organisation claude.ai sans toucher à chaque machine
Politique MDM ou au niveau du système d'exploitation Comme un profil de configuration macOS ou une valeur de registre Windows HKLM, via Jamf, Intune, Group Policy, ou un outil similaire ; consultez où chaque mécanisme stocke la politique Lus au démarrage et vérifiés pour les modifications toutes les 30 minutes Vous gérez déjà les appareils avec MDM ou Group Policy
Basé sur fichier Comme managed-settings.json dans un répertoire système sur chaque machine ; consultez où chaque mécanisme stocke la politique Lus au démarrage et rechargés quand un fichier change Machines sans MDM, hôtes Linux, ou images que vous construisez vous-même
Registre HKCU, Windows et WSL Comme une valeur de registre Windows HKCU ; consultez où chaque mécanisme stocke la politique Lus au démarrage et vérifiés pour les modifications toutes les 30 minutes ; Claude Code ne l'utilise que quand aucun document d'administration n'est présent au-dessus et aucun paramètre parent fourni par l'hôte ne fournit une clé restrictive Vous ne pouvez pas écrire la clé au niveau de la machine HKLM

Les modèles de démarrage pour Jamf, Iru, Intune et Group Policy se trouvent dans le référentiel d'exemples MDM.

Pour les serveurs MCP gérés, que vous déployez aux côtés de l'un de ceux-ci via managed-mcp.json ou que vous fournissez via la clé managedMcpServers, consultez Configuration MCP gérée.

Où et quand une politique s'applique

Une politique déployée atteint les sessions du développeur comme suit :

  • Surfaces : sur la machine du développeur, le terminal, les extensions VS Code et JetBrains, l'onglet Code de l'application de bureau, et les sessions Agent SDK lisent toutes ces sources. Les sessions Agent SDK chargent les paramètres gérés même quand settingSources exclut les fichiers utilisateur, projet et local.

  • Sessions cloud : une session dans un environnement hébergé par Anthropic ne lit pas un profil MDM ou un fichier d'appareil, donc la politique pour cela doit provenir des paramètres gérés par le serveur. Une session dans un environnement auto-hébergé lit également le fichier de paramètres gérés dans son image de runner, par défaut uniquement quand les paramètres gérés par le serveur ne livrent aucune clé de politique, à l'exception des clés que Claude Code lit de chaque source d'administration. Comment Claude Code combine les sources gérées couvre l'opt-in qui s'applique aux deux.

  • Sessions Cowork : Cowork dans l'application Claude Desktop exécute ses sessions sur Claude Code. Dans une session Cowork, Claude Code ne récupère jamais les paramètres gérés par le serveur de la console d'administration claude.ai, même quand l'utilisateur se connecte avec un compte Team ou Enterprise, donc la politique qui s'applique dépend de l'endroit où la session s'exécute :

    • Sur la machine de l'utilisateur : par défaut, Claude Code dans une session Cowork lit la politique MDM ou au niveau du système d'exploitation et le fichier de paramètres gérés sur cet appareil, donc déployez la politique là.
    • Dans un sandbox VM complet : quand votre configuration gérée Claude Desktop définit requireCoworkFullVmSandbox, Claude Code s'exécute à l'intérieur d'une machine virtuelle où la politique MDM de l'appareil et le fichier de paramètres gérés ne sont pas présents.
    • Sessions Cowork distantes : celles-ci s'exécutent sur des machines virtuelles gérées par Anthropic, où Claude Code n'a pas de politique d'appareil à lire.

    Où que la session s'exécute, claude.ai applique les listes strictKnownMarketplaces et blockedMarketplaces de la console d'administration elle-même quand quelqu'un ajoute une marketplace à partir d'un référentiel git sur claude.ai ou à partir de Personnaliser dans l'onglet Cowork. Comment fonctionnent les restrictions décrit cette vérification. Le tableau couverture de surface compare Cowork avec les autres surfaces.

  • Sessions en cours d'exécution : la plupart des modifications atteignent une session en cours d'exécution selon le calendrier du tableau de mécanisme de livraison, sans redémarrage.

  • Modifications qui nécessitent une approbation : à part les mises à jour qui attendent le prochain lancement, une modification gérée par le serveur d'un paramètre qui nécessite une approbation, comme un hook ou une variable env, attend que le développeur accepte la boîte de dialogue dans une session interactive, et s'applique pour l'exécution actuelle dans une session qu'une extension IDE ou l'Agent SDK héberge. Les autres modifications gérées par le serveur s'appliquent au prochain sondage.

  • Sessions longue durée : une session laissée ouverte pendant des semaines peut toujours être en retard sur un déploiement. requiredMinimumVersion bloque un binaire obsolète de démarrer et ne termine pas une session qui s'exécute déjà.

Où chaque mécanisme stocke la politique

Les clés sont les mêmes partout, mais chaque mécanisme les stocke dans un endroit et une forme différents :

  • Gérée par le serveur : les serveurs d'Anthropic, ou votre passerelle, détiennent la politique. Claude Code conserve un cache local qu'il applique au démarrage et remplace à chaque récupération réussie.
  • Profil de configuration macOS : le domaine des préférences gérées com.anthropic.claudecode. Utilisez les mêmes clés de niveau supérieur que managed-settings.json, avec les paramètres imbriqués comme dictionnaires et les listes comme tableaux plist.
  • Registre Windows HKLM : le JSON comme valeur REG_SZ ou REG_EXPAND_SZ nommée Settings sous HKLM\SOFTWARE\Policies\ClaudeCode.
  • Basé sur fichier : managed-settings.json, un répertoire optionnel managed-settings.d/, et managed-mcp.json dans le répertoire système : /Library/Application Support/ClaudeCode/ sur macOS, /etc/claude-code/ sur Linux et WSL, et C:\Program Files\ClaudeCode\ sur Windows. Claude Code ne lit pas le chemin Windows hérité C:\ProgramData\ClaudeCode\managed-settings.json.
  • Registre Windows HKCU : la même valeur Settings sous HKCU\SOFTWARE\Policies\ClaudeCode.

Diviser une politique basée sur fichier entre les équipes

Si plusieurs équipes possèdent des parties d'une politique, mettez chaque partie dans son propre fichier dans managed-settings.d/, à côté de managed-settings.json dans le même répertoire système, au lieu de modifier un fichier partagé.

Claude Code fusionne d'abord managed-settings.json, puis chaque fichier *.json du répertoire dans l'ordre alphabétique. Nommez les fichiers avec des préfixes numériques pour contrôler l'ordre, comme 10-telemetry.json et 20-security.json. Claude Code ignore les fichiers cachés et les fichiers qui ne se terminent pas par .json.

Quand deux fichiers définissent la même clé, Claude Code les combine selon ces règles :

  • Valeurs uniques, comme "model": "opus" ou "cleanupPeriodDays": 7 : la valeur du fichier ultérieur remplace celle du fichier antérieur
  • Listes, comme permissions.deny ou sandbox.network.allowedDomains : les deux listes se combinent, avec les doublons supprimés
  • Blocs imbriqués, comme env ou sandbox : les deux blocs fusionnent clé par clé, et chaque clé à l'intérieur suit ces mêmes règles
  • fallbackModel : la chaîne ultérieure remplace entièrement la chaîne antérieure
  • extraKnownMarketplaces et managedMcpServers : une entrée ultérieure avec le même nom remplace entièrement celle antérieure
  • modelPicker : la lineup ultérieure remplace entièrement la lineup antérieure

Comment Claude Code combine les sources gérées

Quand votre organisation livre plus d'une source gérée à la même machine, la clé managedSourcesBehavior décide ce que Claude Code fait avec les autres :

  • "first-wins", la valeur par défaut : Claude Code utilise la source la mieux classée qui livre au moins une clé de politique et ignore le reste plutôt que de les fusionner, à l'exception des clés dans Clés lues de chaque source d'administration. Claude Code n'affiche aucun avertissement pour les sources qu'il ignore ; /status nomme la source qu'il a utilisée et celles qu'il a ignorées.
  • "merge" : Claude Code applique chaque source d'administration qui livre une clé de politique et les combine par type de clé : sur la plupart des clés, la valeur de la source la mieux classée s'applique, les listes s'unissent, et les verrous prennent la valeur la plus stricte. Composer chaque source gérée dit où définir la clé et comment chaque type de clé se combine. Nécessite Claude Code v2.1.242 ou ultérieur.

Les deux paramètres classent les sources de la même manière. Ces termes reviennent dans cette section :

  • Clé de politique : toute clé de paramètres autre que les deux clés de contrôle, wslInheritsWindowsSettings et managedSourcesBehavior. Un fichier de paramètres gérés ou une politique MDM qui contient uniquement ceux-ci ne compte pas, et Claude Code passe à la source suivante.
  • Source d'administration : l'une des trois premières sources ci-dessous. Le registre HKCU modifiable par l'utilisateur n'en est pas une.

Claude Code vérifie les sources dans cet ordre, priorité la plus élevée en premier :

  1. Paramètres distants, livrés de claude.ai comme paramètres gérés par le serveur ou par une passerelle d'applications Claude. Claude Code récupère cette source uniquement quand la session s'authentifie à l'API d'Anthropic directement avec une connexion ou clé éligible, ou se connecte à une passerelle avec /login. Sur d'autres fournisseurs, ou quand ANTHROPIC_BASE_URL pointe ailleurs que l'API d'Anthropic, il commence à la source suivante
  2. Politiques MDM ou au niveau du système d'exploitation : le plist macOS ou la clé de registre HKLM
  3. Fichiers de paramètres gérés, managed-settings.d/*.json et managed-settings.json fusionnés ensemble
  4. Le registre HKCU, sur Windows, et sur WSL une fois que le registre HKLM ou le fichier de paramètres gérés Windows active wslInheritsWindowsSettings et la valeur HKCU le définit également. Claude Code ne le lit que quand aucune source d'administration n'est présente au-dessus et aucun paramètre parent fourni par l'hôte ne fournit une clé restrictive

Claude Code n'applique jamais le registre HKCU modifiable par l'utilisateur sous un document d'administration qui est présent. Un document est présent quand il définit une clé de politique à une valeur autre que null, même une valeur que Claude Code ne peut pas lire. Une valeur HKLM, un fichier de paramètres gérés, ou un répertoire managed-settings.d qui existe mais ne peut pas être lu est présent aussi. Sur WSL, /etc/claude-code est également modifiable par l'utilisateur, et l'entrée wslInheritsWindowsSettings dit quand les documents Windows se situent au-dessus.

Ce diagramme montre le classement, avec des exemples des clés inter-sources que Claude Code lit des trois premières sources sous l'un ou l'autre paramètre :

Diagramme montrant les quatre sources de paramètres gérés classées des paramètres distants en haut jusqu'à MDM, fichiers de paramètres gérés, et le registre HKCU en bas. Par défaut, la première source avec une clé de politique fournit la politique et le reste est ignoré ; avec managedSourcesBehavior défini sur merge, chaque source d'administration avec une clé de politique contribue, combinée par type de clé, et le registre HKCU reste en dehors. Un panneau latéral montre que les clés inter-sources telles que les verrous sandbox, forceRemoteSettingsRefresh, et la fusion env par variable sont lues de chaque source d'administration, ce qui exclut le registre HKCU. Diagramme montrant les quatre sources de paramètres gérés classées des paramètres distants en haut jusqu'à MDM, fichiers de paramètres gérés, et le registre HKCU en bas. Par défaut, la première source avec une clé de politique fournit la politique et le reste est ignoré ; avec managedSourcesBehavior défini sur merge, chaque source d'administration avec une clé de politique contribue, combinée par type de clé, et le registre HKCU reste en dehors. Un panneau latéral montre que les clés inter-sources telles que les verrous sandbox, forceRemoteSettingsRefresh, et la fusion env par variable sont lues de chaque source d'administration, ce qui exclut le registre HKCU.

Clés lues de chaque source d'administration

Sous le paramètre par défaut "first-wins", Claude Code lit la plupart des clés uniquement de la source qu'il a sélectionnée, et ignore une valeur dans une source de rang inférieur même quand la source sélectionnée laisse cette clé non définie.

Quelques clés fonctionnent différemment. Claude Code les lit de chaque source d'administration, donc une politique MDM ou un fichier de paramètres gérés de rang inférieur peut toujours les définir quand la source sélectionnée ne le fait pas. Claude Code laisse le registre HKCU modifiable par l'utilisateur en dehors de cette analyse ; quand HKCU est la seule source et qu'aucun hôte ne fournit de paramètres parent, HKCU s'applique comme n'importe quelle source sélectionnée.

Les clés inter-sources incluent :

  • sandbox.network.allowManagedDomainsOnly et sandbox.filesystem.allowManagedReadPathsOnly : un true dans n'importe quelle source d'administration active le verrou. Pendant qu'un verrou est actif, Claude Code unit la liste d'autorisation qu'il verrouille, sandbox.network.allowedDomains ensemble avec les règles d'autorisation WebFetch(domain:...), ou sandbox.filesystem.allowRead, de chaque source d'administration. Sans le verrou, Claude Code traite la liste d'autorisation comme n'importe quelle autre clé, donc sous "first-wins" la liste d'autorisation d'une source d'administration non sélectionnée est ignorée

  • allowAllClaudeAiMcps

  • allowManagedMcpServersOnly : un true dans n'importe quelle source d'administration active le verrou de liste d'autorisation MCP. Pendant que le verrou est actif, la liste allowedMcpServers gérée provient de la source d'administration la mieux classée qui en définit une. Une liste gérée par le serveur remplace la liste d'une source inférieure plutôt que de se combiner avec elle.

    Si aucune source d'administration ne définit une liste, chaque serveur qui passe la liste de refus se charge, à moins que les paramètres parent ne fournissent une liste.

    Sans le verrou, Claude Code lit allowedMcpServers de la source gérée qu'il applique, donc sous "first-wins" la liste d'une source d'administration non sélectionnée est ignorée. Nécessite Claude Code v2.1.273 ou ultérieur

  • deniedMcpServers et disableClaudeAiConnectors : une entrée ou un true dans n'importe quelle source d'administration s'applique. Nécessite Claude Code v2.1.273 ou ultérieur

  • Les chemins binaires sandbox sandbox.bwrapPath et sandbox.socatPath

  • Le binaire sandbox ripgrep, sandbox.ripgrep

  • sandbox.filesystem.disabled et sandbox.network.strictAllowlist

  • useAutoModeDuringPlan, syncClaudeAiSkills, et syncClaudeAiPlugins, où un false de n'importe quelle source d'administration désactive le comportement. Un false dans les paramètres utilisateur ou local du développeur le désactive également ; chaque clé ne peut que refuser

  • enableArtifact, où un false de n'importe quelle source d'administration désactive l'outil Artifact. Un false dans les paramètres utilisateur, projet ou local du développeur le désactive également, et aucune source ne le réactive ; consultez quelles valeurs de niveau inférieur comptent toujours. Nécessite Claude Code v2.1.242 ou ultérieur

  • maxEffortLevel, où le plafond le plus bas dans n'importe quelle source d'administration s'applique. Si un développeur définit un plafond plus bas dans ses propres paramètres ou avec --settings, Claude Code applique celui-ci ; aucune source ne peut augmenter le plafond. Nécessite Claude Code v2.1.267 ou ultérieur

  • Une opt-out de commit-trailer dans attribution, ou dans le includeCoAuthoredBy déprécié, de n'importe quel niveau

  • forceRemoteSettingsRefresh

  • env, fusionné par variable de chaque source d'administration : chaque variable provient de la source de priorité la plus élevée qui la définit, donc les sources inférieures remplissent les variables que les sources supérieures laissent non définies. Quelques variables suivent leurs propres règles ; Exceptions par clé de chaque source gérée nomme chacune. Nécessite Claude Code v2.1.223 ou ultérieur. Avant v2.1.223, Claude Code appliquait uniquement le bloc env entier de la source sélectionnée

Les clés de connexion à la passerelle suivent une règle séparée. Claude Code ne les lit jamais à partir des paramètres gérés par le serveur, donc pendant que les paramètres gérés par le serveur sont la source sélectionnée, la source d'administration la mieux classée sur la machine qui porte une clé de politique les fournit toujours. Une valeur dans une source d'administration classée en dessous de celle-ci, ou dans le registre HKCU, est ignorée.

Quand une source d'administration définit allowManagedMcpServersOnly ou une liste allowedMcpServers et que cette valeur n'est pas celle en vigueur, /status et claude doctor nomment cette source et cette clé.

Composer chaque source gérée

Pour que Claude Code applique chaque source d'administration que votre organisation livre, définissez managedSourcesBehavior sur "merge" dans la source la mieux classée que vous déployez. Claude Code lit la clé uniquement de la source la mieux classée qui porte soit la clé soit une clé de politique, donc une source inférieure ne peut pas se faire fusionner avec la source au-dessus, et une machine qui ne reçoit jamais les paramètres gérés par le serveur a besoin de la clé dans son profil MDM également. Le registre HKCU modifiable par l'utilisateur ne fusionne jamais avec une autre source. Nécessite Claude Code v2.1.242 ou ultérieur.

Sous "merge", Claude Code ajoute les entrées de liste d'une source inférieure, comme les règles permissions.allow et les hooks, à la politique, donc activez-le uniquement quand chaque source classée en dessous de votre source la plus élevée est sous le contrôle d'un administrateur.

Ce tableau montre comment Claude Code combine chaque type de clé sous "merge". L'entrée managedSourcesBehavior nomme chaque clé dans trois des lignes : listes d'autorisation de restriction, valeurs prises entièrement, et clés lues uniquement de la source la mieux classée.

Type de clé Comment Claude Code la combine Exemples
Listes Combine les entrées de chaque source permissions.allow, hooks, sandbox.network.allowedDomains, deniedMcpServers, deniedModels
Verrous Applique la valeur la plus stricte que n'importe quelle source définit ; une valeur plus souple s'applique uniquement de la source la mieux classée allowManagedHooksOnly, permissions.disableBypassPermissionsMode, crossSessionInbound, availableModelsMatch
Listes d'autorisation de restriction Prend la liste entière de la source la mieux classée qui la définit, sans ajouter d'entrées de sources inférieures availableModels, allowedMcpServers, strictKnownMarketplaces, allowedChannelPlugins, et la chaîne fallbackModel
Valeurs prises entièrement Prend la valeur entière de la source la mieux classée qui la définit, sans combiner d'entrées ou de champs de sources inférieures sandbox.credentials.awsPairs, sandbox.ripgrep
Serveurs MCP fournis Combine les noms de serveur de chaque source ; quand deux sources définissent le même nom, applique l'entrée entière de la source la mieux classée managedMcpServers
Clés lues uniquement de la source la mieux classée Ignore la clé dans chaque source inférieure, même quand la source la mieux classée la laisse non définie Les aides aux identifiants comme apiKeyHelper, les épingles de connexion comme forceLoginOrgUUID, modelPicker, permissions.defaultMode
env Fusionne par variable de chaque source d'administration sous l'un ou l'autre paramètre, comme Clés lues de chaque source d'administration le décrit
Chaque autre clé Prend la valeur de la source la mieux classée qui la définit model, cleanupPeriodDays

Pour confirmer quelles sources se sont combinées sur une machine, lisez la ligne Setting sources dans /status ; cette section dit ce que chaque étiquette signifie.

Calculer la politique avec un programme d'aide

Un policyHelper est un exécutable que votre politique MDM ou fichier de paramètres gérés nomme, et Claude Code l'exécute pour calculer les paramètres gérés au démarrage. Quand la source sélectionnée en configure un et que l'aide émet un objet managedSettings, cette sortie change ce que Claude Code lit :

Pour savoir quels aides échouent, et ce que Claude Code fait quand l'une le fait, consultez Défaillances d'aide.

Laisser un hôte d'intégration ajouter une politique

Quand une autre application lance Claude Code, comme Claude Desktop, une extension IDE, ou une application Agent SDK, cet hôte peut passer ses propres paramètres gérés via l'option SDK managedSettings. Claude Code appelle ces paramètres parent.

Par défaut, Claude Code ignore les paramètres parent chaque fois qu'une source d'administration est présente : paramètres gérés par le serveur, une politique MDM ou au niveau du système d'exploitation, ou un fichier de paramètres gérés.

Pour que Claude Code fusionne les paramètres parent aux côtés d'une source d'administration, définissez parentSettingsBehavior sur "merge" dans la source gérée de priorité la plus élevée ; Claude Code lit la clé de cette source uniquement.

Claude Code conserve alors uniquement les valeurs de l'hôte qui restreignent ce que Claude peut faire, avec une lacune à connaître : à moins que vous ne définissiez également les verrous allowManaged*Only, les règles d'autorisation de permission de l'hôte et les listes d'autorisation sandbox s'appliquent toujours. Consultez Restreindre les paramètres parent pour les verrous.

Un policyHelper peut désactiver la fusion parent indépendamment de cette clé ; son entrée dit quand.

Claude Code applique également ces vérifications aux valeurs fournies par le parent d'elles-mêmes :

  • Quand n'importe quelle source d'administration définit allowManagedPermissionRulesOnly, Claude Code supprime les règles d'autorisation de permission fournies par le parent et additionalDirectories au fur et à mesure qu'il les lit, même quand une source de priorité plus élevée laisse la clé non définie. L'effet de la clé sur vos propres règles de permission provient des paramètres gérés que Claude Code applique, ou des paramètres parent que vous avez choisi de fusionner

  • Claude Code applique la valeur forceLoginOrgUUID ou allowedMcpServers dans les paramètres gérés qu'il applique et bloque une valeur fournie par le parent. Une valeur dans une source d'administration inférieure que Claude Code n'applique pas ne s'applique ni ne bloque celle du parent.

    Sur Claude Code v2.1.273 ou ultérieur, pendant que allowManagedMcpServersOnly est actif, la liste allowedMcpServers de la source d'administration la mieux classée qui en définit une s'applique et bloque celle du parent, comme une clé inter-source. La liste du parent s'applique uniquement quand aucune source d'administration n'en définit une. L'entrée managedSourcesBehavior dit quelle source fournit chaque clé sous "merge". Avant v2.1.223, une valeur dans n'importe quelle source d'administration bloquait celle du parent

  • Pour availableModels, Claude Code applique la valeur dans les paramètres gérés qu'il applique et bloque une liste fournie par le parent

  • Pour strictKnownMarketplaces, Claude Code applique de la même manière la liste dans les paramètres gérés qu'il applique et bloque une liste fournie par le parent. La liste du parent s'applique uniquement quand aucune source gérée appliquée ne la définit. Nécessite Claude Code v2.1.282 ou ultérieur

  • Un blockedMarketplaces fourni par le parent s'applique en plus de toute liste de blocage qu'une source gérée définit. Nécessite Claude Code v2.1.282 ou ultérieur

Garder l'accès au dossier Cowork quand seules les règles gérées s'appliquent

Cowork dans l'application Claude Desktop exécute ses sessions sur Claude Code et accorde à chaque session l'accès à ses dossiers de travail, comme le dossier que l'utilisateur connecte, via les règles d'autorisation qu'il fournit quand il lance la session. Quand votre politique gérée définit allowManagedPermissionRulesOnly, Claude Code conserve uniquement les règles d'autorisation dans la politique gérée : il supprime les règles d'autorisation qu'un hôte fournit comme paramètres parent, comme --allowedTools, ou dans un fichier de paramètres, donc les écritures dans ces dossiers perdent leur pré-approbation. Dans une session Cowork qui demande avant les modifications, Cowork ne peut pas afficher l'invite, et Claude signale chaque écriture comme bloquée car le chemin se résout à un emplacement protégé ou un chemin en dehors du dossier connecté.

Pour restaurer les écritures, ajoutez des règles d'autorisation pour ces dossiers à la source gérée que Claude Code sélectionne sur ces machines : sur une flotte gérée par MDM, c'est la politique MDM plutôt qu'un fichier de paramètres gérés séparé. Cet exemple utilise la forme de fichier, et une politique MDM prend les mêmes clés. Il garde allowManagedPermissionRulesOnly défini et permet les modifications sous un dossier CoworkProjects dans le répertoire personnel de chaque utilisateur ; remplacez le chemin par les dossiers que vos utilisateurs connectent :

{
  "allowManagedPermissionRulesOnly": true,
  "permissions": {
    "allow": [
      "Edit(~/CoworkProjects/**)"
    ]
  }
}

Après avoir déployé la politique, Claude peut enregistrer les fichiers sous ce dossier dans une nouvelle session Cowork. Règles Read et Edit couvrent la syntaxe du chemin, y compris la forme // pour les chemins absolus.

Ce qu'un développeur peut changer

Les fichiers de paramètres propres d'un développeur, les valeurs --settings, et les fichiers de projet ne remplacent jamais une valeur gérée ; les exceptions permettent uniquement à une valeur plus stricte de niveau inférieur de compter. Ces cas se situent en dehors de cette règle :

  • Le modèle pour une session : un model géré est une valeur par défaut, pas un verrou. --model et ANTHROPIC_MODEL choisissent toujours le modèle pour cette session, donc déployez availableModels pour restreindre le choix.
  • Droits d'administrateur local : un développeur qui est administrateur sur la machine peut modifier la source gérée elle-même, c'est pourquoi les outils MDM peuvent redéployer le profil ou le fichier selon un calendrier et pourquoi le registre HKLM et le domaine des préférences gérées macOS existent.
  • Le cache géré par le serveur : les paramètres gérés par le serveur proviennent des serveurs d'Anthropic, et une modification du cache local dure uniquement jusqu'à la prochaine récupération réussie.
  • Autres outils : les paramètres gérés lient uniquement Claude Code. Un développeur qui appelle l'API à partir d'un autre outil n'est pas sous eux.

Vérifier qu'une politique est en vigueur

Un développeur signale qu'une politique ne s'applique pas, ou vous voulez confirmer qu'un déploiement a atterri avant de le pousser à la flotte. Deux commandes sur cette machine répondent : /status montre quelle source gérée Claude Code a sélectionnée, et claude doctor énumère ce qu'il a supprimé.

Lire la source dans /status

Sur la machine du développeur, exécutez /status dans Claude Code et lisez la ligne Setting sources. Quand une source gérée est en vigueur, la ligne énumère Enterprise managed settings avec la source que Claude Code a sélectionnée entre parenthèses :

  • (remote) : paramètres gérés par le serveur de claude.ai ou une passerelle
  • (plist) ou (HKLM) : une politique MDM ou au niveau du système d'exploitation
  • (file), (drop-ins), ou (file + drop-ins) : managed-settings.json, le répertoire drop-in, ou les deux
  • (remote + file, merged), ou une autre liste se terminant par , merged : votre organisation compose chaque source gérée, et Claude Code a fusionné les sources énumérées dans la politique. Une source inférieure peut toujours fournir des variables env sans apparaître dans la liste. Nécessite Claude Code v2.1.242 ou ultérieur
  • (HKCU) : le registre modifiable par l'utilisateur fallback
  • (parent process) : un hôte d'intégration a fourni des paramètres restrictifs
  • (helper) : un policyHelper configuré par la source MDM ou fichier sélectionnée

Quand Claude Code a trouvé une source gérée sur la machine et ne l'a pas sélectionnée, une deuxième ligne, Skipped sources, nomme chaque source de ce type. Lisez-la pour distinguer une politique qui n'a jamais atteint la machine d'une qui l'a atteinte et qu'une source de priorité plus élevée a remplacée. Nécessite Claude Code v2.1.242 ou ultérieur.

Quand la politique ne s'applique pas, la ligne Setting sources vous dit lequel de deux problèmes vous avez :

  • La ligne est manquante : Claude Code n'a trouvé aucune source gérée qui livre une clé de politique.

    Si vous avez déployé un fichier de paramètres gérés, vérifiez qu'il se trouve au chemin du système d'exploitation et qu'il contient une clé de politique plutôt que uniquement les clés de contrôle. Un fichier qui n'est pas un JSON valide ne produit pas cet état ; Claude Code refuse de démarrer à la place.

    Quand vous avez déployé via les paramètres gérés par le serveur à la place, exécutez claude doctor, qui signale le résultat de la récupération.

  • La ligne nomme une source autre que celle que vous avez déployée : une source de priorité plus élevée est présente et Claude Code a ignoré la vôtre, et Skipped sources l'énumère. Comment Claude Code combine les sources gérées donne l'ordre.

Trouver les entrées que Claude Code a supprimées

Si votre fichier de paramètres gérés, profil MDM, valeur de registre, ou charge utile gérée par le serveur échoue la validation du schéma, Claude Code ignore d'abord chaque entrée individuelle qu'il peut réparer, comme une règle de permission invalide, et avertit à propos de chacune. Claude Code supprime ensuite toute valeur qui échoue toujours, sauf si la valeur appartient à l'une des clés qui échouent fermées à la place.

Claude Code est plus strict avec le managedSettings qu'un policyHelper émet : il fait les mêmes réparations d'entrée, mais toute violation de schéma qui survit échoue l'exécution entière de l'aide, et au démarrage Claude Code refuse de démarrer, de la même manière que pour une aide qui se termine avec un code non nul.

Quand un fichier de paramètres gérés, un fichier drop-in, un plist MDM, ou une valeur de registre HKLM est présent mais ne peut pas être analysé comme un objet JSON, Claude Code refuse de démarrer et imprime une erreur nommant la source, même quand une autre source d'administration livre une politique valide. Chaque source échoue de cette manière quand :

  • Fichier de paramètres gérés ou fichier drop-in : le fichier n'est pas un JSON valide, ou son niveau supérieur n'est pas un objet
  • Plist MDM : le plutil de macOS signale le plist malformé, ou son contenu converti n'est pas un objet JSON
  • Valeur de registre HKLM : la valeur Settings n'est pas une chaîne, est vide, ou ne contient pas un objet JSON

Trois états de source ne causent pas ce refus :

  • Un fichier, profil, ou valeur de registre absent n'est pas une défaillance ; Claude Code s'exécute sans cette source.
  • Un fichier de paramètres gérés vide compte comme {}.
  • Une valeur malformée dans la clé de registre HKCU modifiable par l'utilisateur ne bloque jamais le lancement. Claude Code la signale comme un avis dans /status et claude doctor à la place.

Si un fichier de paramètres gérés, un fichier drop-in, ou un répertoire managed-settings.d/ ne peut pas être lu et qu'aucune source d'administration ne fournit une politique, les sessions connectées avec des identifiants claude.ai ou Claude Console se terminent au démarrage avec un message pour contacter un administrateur.

Pour trouver une entrée supprimée, regardez dans l'un de trois endroits :

  • Les sessions interactives affichent une boîte de dialogue au démarrage énumérant les entrées invalides.
  • Les exécutions non interactives avec -p impriment un résumé sur stderr.
  • claude doctor énumère chaque entrée invalide avec sa source et son champ.

Clés qui échouent fermées

Quand une source gérée définit une clé de niveau supérieur qui a une seule valeur restrictive, comme allowManagedPermissionRulesOnly, disableAutoMode, ou skipDangerousModePermissionPrompt, à quelque chose que Claude Code ne peut pas lire, la clé se lit comme cette valeur jusqu'à ce que vous la corrigiez. Le rapport dit que la clé was present but invalid et nomme la valeur que Claude Code la traite comme. Pour une clé à l'intérieur de sandbox, consultez Valeurs invalides à l'intérieur de sandbox.

Ces cas ne échouent pas fermés :

  • Un null supprime la clé.
  • Un disableAllHooks invalide, même un booléen entre guillemets, est supprimé avec un avertissement, car appliquer true déchargerait également les hooks que vos propres paramètres gérés déploient.
  • Pour chaque autre clé booléenne que la règle couvre, la chaîne "true" ou "false" se lit comme ce booléen, avec un avis dans /status vous demandant de supprimer les guillemets.

Claude Code répare les blocs permissions, autoMode, worktree, et attribution par champ au lieu de les supprimer entièrement :

  • Un verrou à l'intérieur d'un, comme permissions.disableBypassPermissionsMode, se lit comme sa valeur restrictive.
  • Un permissions.defaultMode invalide se lit comme default.
  • Tandis qu'une liste deny ou ask dans permissions ne peut pas être lue du tout, Claude Code retient allow et additionalDirectories, donc les subventions ne s'appliquent jamais sans les restrictions écrites à côté. Le rapport nomme chaque subvention retenue et la liste qui ne pouvait pas être lue.
  • Dans autoMode, une liste soft_deny ou hard_deny qui ne peut pas être lue, ou qui a perdu une entrée invalide, retient allow et environment de la même manière.

La règle d'échec fermé pour les clés avec une seule valeur restrictive et les réparations par champ nécessitent Claude Code v2.1.282 ou ultérieur.

Ces clés ont leur propre fallback :

Champ Comportement quand présent mais invalide
allowedMcpServers Appliquée comme une liste d'autorisation vide jusqu'à ce que la valeur soit corrigée, donc aucun serveur MCP que les utilisateurs ajoutent n'est admis. Les serveurs que votre organisation livre via managedMcpServers se chargent toujours, et les serveurs managed-mcp.json se chargent selon Comment un serveur est évalué. Une entrée invalide individuelle est supprimée et le sous-ensemble valide est appliqué.
allowedHttpHookUrls Claude Code applique une liste d'autorisation gérée vide jusqu'à ce que vous corrigiez la valeur, donc un hook HTTP s'exécute uniquement si un autre fichier de paramètres énumère son URL. Si seule une entrée individuelle est invalide, Claude Code supprime cette entrée et applique le reste.
httpHookAllowedEnvVars Claude Code applique une liste d'autorisation gérée vide jusqu'à ce que vous corrigiez la valeur, donc une variable d'en-tête est interpolée uniquement si un autre fichier de paramètres la nomme. Si seule une entrée individuelle est invalide, Claude Code supprime cette entrée et applique le reste.
allowedChannelPlugins Claude Code applique une liste d'autorisation vide jusqu'à ce que vous corrigiez la valeur, donc aucun plugin de canal passé à --channels n'est admis. Si seule une entrée individuelle est invalide, il supprime cette entrée et applique le reste.
strictKnownMarketplaces Appliquée comme une liste d'autorisation vide jusqu'à ce que la valeur soit corrigée, donc aucune source de marketplace n'est admise. Une entrée individuelle qui est invalide ou ne peut pas être appliquée, comme une regex hostPattern qui ne compile pas, est supprimée et le sous-ensemble valide est appliqué.
availableModels Appliquée comme une liste d'autorisation vide jusqu'à correction, donc seul le modèle par défaut est disponible ; une entrée non-chaîne est supprimée et le sous-ensemble valide est appliqué.
availableModelsMatch Traitée comme exact jusqu'à ce que la valeur soit corrigée.
forceLoginOrgUUID Aucune organisation n'est autorisée à se connecter jusqu'à ce que la valeur soit corrigée.
gatewayInternalNetworks Quand la valeur invalide provient de la source gérée la plus élevée sur la machine, /login refuse chaque nouvelle connexion passerelle cloud sur cette machine jusqu'à ce que la valeur soit corrigée.
crossSessionInbound Traitée comme refuse, la valeur la plus restrictive, donc les messages inter-sessions entrants sont refusés jusqu'à ce que la valeur soit corrigée. Le développeur voit un avertissement.
deniedMcpServers Une entrée invalide individuelle est supprimée et le sous-ensemble valide est appliqué. Une valeur entièrement invalide est supprimée avec un avertissement, car refuser chaque serveur bloquerait les serveurs que la politique n'a jamais nommés.
deniedModels Une entrée non-chaîne est supprimée et le reste de la liste est appliqué. Une valeur entièrement invalide est supprimée avec un avertissement et ne bloque aucun modèle jusqu'à ce qu'elle soit corrigée.
blockedMarketplaces Une entrée invalide individuelle est supprimée et le sous-ensemble valide est appliqué. Une entrée qui analyse mais ne peut jamais correspondre, comme une regex hostPattern qui ne compile pas, est conservée avec un avertissement. Elle ne bloque rien jusqu'à correction, mais les restrictions de marketplace restent actives. Une valeur entièrement invalide est supprimée avec un avertissement, car bloquer chaque marketplace bloquerait les sources que la politique n'a jamais nommées.
sandbox Quand une valeur à l'intérieur du bloc est invalide, Claude Code ne supprime pas le bloc entier. Pour ce qui arrive à chaque type de champ invalide, consultez Valeurs invalides à l'intérieur de sandbox.
sandbox.credentials Une entrée invalide récupérable est dégradée à mode: "deny" avec un avertissement ; une irrécupérable est supprimée ; les entrées valides restent appliquées. Consultez entrées de credential invalides.
strictPluginOnlyCustomization Traitée comme true, verrouillant les quatre surfaces, quand la valeur n'est ni un booléen ni un tableau. Une entrée de tableau que cette version ne reconnaît pas comme une surface ne verrouille rien ; une note de statut compte ces entrées pour que vous puissiez les vérifier pour les fautes de frappe.
enabledPlugins Une entrée invalide est supprimée avec un avertissement et les autres entrées restent appliquées. Une valeur qui n'est pas une carte d'ID de plugin, ou dont chaque entrée est invalide, est supprimée entièrement avec un avertissement.

allowedHttpHookUrls et httpHookAllowedEnvVars fusionnent entre les fichiers de paramètres, donc les entrées dans vos paramètres utilisateur, projet ou local s'appliquent toujours tandis que la liste gérée est vide.

Les fallbacks pour ces deux clés et pour allowedChannelPlugins nécessitent Claude Code v2.1.267 ou ultérieur ; les versions antérieures suppriment la clé entière quand sa valeur ou une entrée est invalide. Les fallbacks pour strictKnownMarketplaces et blockedMarketplaces nécessitent Claude Code v2.1.277 ou ultérieur ; les versions antérieures suppriment la clé entière quand sa valeur ou une entrée est invalide. Les fallbacks pour strictPluginOnlyCustomization et enabledPlugins nécessitent Claude Code v2.1.282 ou ultérieur.

requiredMinimumVersion et requiredMaximumVersion échouent ouvertes par conception : une valeur invalide est supprimée plutôt qu'appliquée.

Cette tolérance s'applique uniquement aux paramètres gérés. Les fichiers de paramètres utilisateur, projet et local restent stricts : un fichier dont le JSON ou la forme de niveau supérieur échoue la validation est rejeté entièrement et signalé, et une entrée individuelle qui échoue, comme une règle de permission malformée, est ignorée avec un avertissement tandis que le reste du fichier s'applique.

Valeurs invalides à l'intérieur de `sandbox`

Quand une valeur dans votre bloc sandbox géré est invalide, Claude Code ne supprime pas le bloc entier, car il valide chaque champ indépendamment. Cette gestion par champ nécessite Claude Code v2.1.283 ou ultérieur. Sur les versions antérieures à v2.1.283, Claude Code supprime chaque champ sandbox sauf credentials quand une valeur en dehors de credentials est invalide.

L'avertissement que vous recevez pour un champ invalide nomme le champ et vous dit ce qui lui arrive. Ce qui arrive dépend de ce que le champ contrôle :

  • Si vous définissez une clé booléenne sur une "true" ou "false" entre guillemets, la valeur compte comme ce booléen. Au lieu d'un avertissement, /status affiche un avis vous demandant de supprimer les guillemets.
  • Si failIfUnavailable est invalide, Claude Code supprime la valeur plutôt que de la traiter comme true, donc une valeur illisible ne bloque jamais les sessions de démarrage sur votre flotte.
  • Claude Code traite chaque autre booléen invalide comme la valeur qui garde le sandbox le plus strict jusqu'à ce que vous la corrigiez. Une clé qui active le sandbox ou l'une de ses restrictions, comme enabled ou network.allowManagedDomainsOnly, compte comme true. Une clé qui l'assouplit, comme allowUnsandboxedCommands, compte comme false.
  • Dans une liste en dehors de credentials, comme excludedCommands ou network.allowedDomains, Claude Code supprime une entrée invalide et garde le reste de la liste. Une liste qui n'est pas un tableau, ou qui n'a aucune entrée valide, ne s'applique pas du tout.
  • Tandis que network.deniedDomains ou une entrée quelconque en elle est invalide, Claude Code retient également network.allowedDomains, donc la liste d'autorisation gérée n'accorde rien jusqu'à ce que vous corrigiez la liste de refus.
  • Tandis que filesystem.denyRead, filesystem.denyWrite, ou une entrée quelconque dans l'une ou l'autre est invalide, Claude Code retient également filesystem.allowRead et filesystem.allowWrite jusqu'à ce que vous corrigiez la liste de refus.

Clés qu'une source gérée seule peut définir

Claude Code lit les clés suivantes uniquement d'une source gérée ; les placer dans les fichiers de paramètres utilisateur ou projet n'a aucun effet.

La plupart d'entre elles sont des verrous : la valeur qu'un verrou gouverne, comme les règles de permission ou sandbox.network.allowedDomains, est une clé ordinaire que n'importe quel niveau peut définir, et le verrou dit à Claude Code d'honorer uniquement la valeur gérée.

Le tableau couvre les contrôles de permission, plugin et livraison. Pour toute clé non énumérée ici, la colonne Scope de l'index de référence des paramètres dit si elle est gérée uniquement ; les clés gérées uniquement restantes là incluent l'URL de connexion à la passerelle, la version, le navigateur, le simulateur mobile, l'hôte SSH, la session locale Desktop, le chemin binaire sandbox, la tarification du modèle, la restriction du modèle, et les contrôles CLAUDE.md.

Paramètre Description
allowAllClaudeAiMcps Charger les connecteurs claude.ai que Claude Code récupère lui-même aux côtés d'un managed-mcp.json déployé au lieu de les supprimer
allowedChannelPlugins Liste d'autorisation des plugins de canal qui peuvent pousser des messages. Remplace la liste d'autorisation Anthropic par défaut quand défini. Nécessite channelsEnabled: true. Consultez Restreindre quels plugins de canal peuvent s'exécuter
allowManagedHooksOnly Quand true, restreint quels hooks s'exécutent ; consultez ce qui s'exécute sous allowManagedHooksOnly pour la liste complète des effets
allowManagedMcpServersOnly Quand true, seul allowedMcpServers des paramètres gérés est respecté. deniedMcpServers fusionne toujours de toutes les sources. Consultez Clés lues de chaque source d'administrateur pour savoir quelles sources gérées peuvent le définir, et Configuration MCP gérée
allowManagedPermissionRulesOnly Rend les paramètres gérés la seule source de paramètres des règles de permission. L'entrée énumère chaque source qu'elle ignore
blockedMarketplaces Liste de blocage des sources de place de marché. Les sources bloquées sont vérifiées avant le téléchargement, donc elles ne touchent jamais le système de fichiers. Consultez restrictions de place de marché gérée
channelsEnabled Autoriser les canaux pour l'organisation. Consultez contrôles d'entreprise pour la valeur par défaut sur chaque plan
disableCommandPluginSources Quand true, bloque entièrement les sources de plugin command, donc la commande déclarée par la place de marché ne s'exécute jamais. Bloque également les commandes headersHelper de la place de marché, sauf pour une place de marché que les paramètres gérés eux-mêmes déclarent. Quand non défini, suit allowManagedHooksOnly. Nécessite Claude Code v2.1.229 ou ultérieur, et le bloc headersHelper nécessite v2.1.238 ou ultérieur
disableSideloadFlags Rejeter les drapeaux --plugin-dir, --plugin-url, --agents, et --mcp-config au démarrage. Dans les sessions cloud, Claude Code supprime les serveurs MCP que le serveur a livrés via --mcp-config, autres que les entrées type: "sdk" en processus, et démarre la session. Nécessite Claude Code v2.1.193 ou ultérieur
forceRemoteSettingsRefresh Quand true, bloque le démarrage CLI jusqu'à ce que les paramètres gérés distants soient fraîchement récupérés et se termine si la récupération échoue. Consultez application fail-closed
managedMcpServers Serveurs MCP distants fournis à chaque utilisateur aux côtés des leurs. Il fournit des serveurs plutôt que de verrouiller quoi que ce soit. Consultez Fournir des serveurs via les paramètres gérés. Nécessite Claude Code v2.1.259 ou ultérieur
managedSourcesBehavior Si Claude Code applique uniquement la source gérée de priorité la plus élevée ou compose chacune d'elles
parentSettingsBehavior Si les paramètres parent fournis par l'hôte fusionnent sous la politique gérée
pluginSuggestionMarketplaces Places de marché dont les plugins Claude Code peut suggérer aux utilisateurs
pluginTrustMessage Message personnalisé ajouté à l'avertissement de confiance du plugin affiché avant l'installation
policyHelper Exécutable qui calcule les paramètres gérés au démarrage ; consultez Calculer les paramètres gérés avec un aide de politique
sandbox.filesystem.allowManagedReadPathsOnly Quand true, seuls les chemins filesystem.allowRead des paramètres gérés sont respectés. denyRead fusionne toujours de toutes les sources
sandbox.network.allowManagedDomainsOnly Honorer uniquement les allowedDomains gérés et les règles d'autorisation WebFetch(domain:...) ; bloquer les autres domaines sans demander
strictKnownMarketplaces Contrôle quelles sources de place de marché de plugin les utilisateurs peuvent ajouter et installer des plugins. Consultez restrictions de place de marché gérée
strictPluginOnlyCustomization Bloquer les skills, agents, hooks, et serveurs MCP des sources utilisateur et projet ; true verrouille les quatre, un tableau nomme lesquels
wslInheritsWindowsSettings Quand défini dans le registre HKLM ou un fichier sous C:\Program Files\ClaudeCode, faire que WSL lise la chaîne de politique Windows, et lire /etc/claude-code uniquement quand aucun document d'administrateur Windows n'est présent ; l'entrée donne l'ordre

Désactiver la télémétrie pour votre organisation

Claude Code envoie la télémétrie opérationnelle d'Anthropic par défaut sur les sessions qui utilisent l'API Anthropic, directement, via une passerelle LLM, ou via un ANTHROPIC_BASE_URL personnalisé ; Comportements par défaut par fournisseur d'API dit quels fournisseurs l'envoient. Pour la désactiver pour chaque développeur sans compter sur la shell de chaque personne, livrez DISABLE_TELEMETRY via le bloc env de vos paramètres gérés. Cet exemple définit DISABLE_TELEMETRY pour tous ceux que la politique atteint :

{
  "env": {
    "DISABLE_TELEMETRY": "1"
  }
}

Claude Code applique une valeur de 1 sans afficher à l'utilisateur la boîte de dialogue d'approbation.

Si vous désactivez la télémétrie, Claude Code arrête d'envoyer les données d'utilisation qui alimentent le tableau de bord d'analyse de votre organisation pour les développeurs que la politique atteint. La variable désactive également la récupération des drapeaux de fonctionnalité pour ces développeurs. Pour Remote Control, consultez les exigences de Remote Control.

Où et quand une politique s'applique dit quel mécanisme de livraison atteint chaque surface, et Disponibilité de la plateforme dit quelles sessions ignorent la récupération des paramètres gérés par le serveur.

Si votre organisation utilise des clés de chiffrement gérées par le client et achemine Claude Code via une passerelle, Configurer les proxies et les passerelles dit pourquoi ces sessions ont besoin de cette variable.

Voir aussi