Gérer les mods pour votre organisation

• Empêcher les mods des utilisateurs de se charger, avec ou sans vos propres mods : Arrêter le chargement des mods installés par les utilisateurs
• Voir ce que vos utilisateurs obtiennent quand vous ne changez rien : Savoir ce qui se passe par défaut
• Laisser les mods activés avec d’autres limites : Choisir le niveau d’autorisation

​

Arrêter le chargement des mods installés par les utilisateurs

{
  "pluginConfigs": {
    "cc-plugin-sec-default@builtin": {
      "options": {
        "allowManagedModsOnly": true
      }
    }
  }
}

• Aucun mod qu’un utilisateur apporte ne se charge : cela couvre un mod dans un plugin que l’utilisateur a installé, un mod chargé avec --plugin-dir, et un mod que Claude a écrit pendant une session
• Les mods de votre organisation se chargent toujours : un mod qui compte comme celui de votre organisation n’est pas vérifié. Tous les autres mods comptent comme ceux d’un utilisateur et ne se chargent pas. Cela inclut un mod dans un plugin que vous activez à partir d’une place de marché GitHub ou autre distante, et un que votre organisation active pour ses membres sur claude.ai. Si aucun ne compte comme le vôtre, aucun mod installé ne se charge.
• Les utilisateurs ne peuvent pas l’annuler : la garde lit l’option uniquement à partir des paramètres gérés, donc la même entrée dans un fichier de paramètres utilisateur, projet ou local, ou dans un fichier passé avec --settings, ne change rien
• Un fichier ou une politique MDM couvre chaque fournisseur : quand vous livrez l’option sous forme de fichier ou via MDM, elle fonctionne de la même manière sur Amazon Bedrock, la plateforme Agent de Google Cloud, et Microsoft Foundry. Pour la livraison depuis la console d’administration claude.ai, voir Disponibilité de la plateforme
• Les autres personnalisations des utilisateurs continuent de fonctionner : leurs hooks dans les fichiers de paramètres, les lignes d’état, et /goal ne sont pas affectés
• Les mods intégrés continuent de s’exécuter : les mods intégrés à Claude Code, comme le support AGENTS.md, ont chacun leur propre commutateur

​

Savoir ce qui se passe par défaut

• Les mods sont activés. Un utilisateur peut installer un plugin qui contient un mod à partir de n’importe quelle place de marché que vos paramètres de plugin autorisent, ou en charger un à partir d’un répertoire avec --plugin-dir.
• Une garde intégrée s’exécute en premier. Claude Code charge un mod intégré nommé sec-default@builtin avant chaque mod qu’un utilisateur installe. Les utilisateurs ne peuvent pas l’éteindre. /plugin et le journal de débogage le listent comme cc-plugin-sec-default. La garde se charge quand l’une de ces conditions est vraie :
  • La machine a des paramètres gérés
  • L’utilisateur est connecté à Claude Code avec un plan Team ou Enterprise
  Un utilisateur qui s’authentifie avec une clé API, ou via Amazon Bedrock, la plateforme Agent de Google Cloud, ou Microsoft Foundry, n’obtient la garde que sur une machine qui a des paramètres gérés.
• La garde protège ce que vous gérez. Le mod d’un utilisateur ne peut pas changer ce que vos hooks gérés reçoivent ou décident, l’invite système, votre CLAUDE.md géré et autres instructions gérées, ce que n’importe quel mod lit comme paramètres, ou les outils et descriptions de vos serveurs MCP gérés.
• Tout le reste est autorisé. La garde n’ajoute aucune autre restriction. Le mod d’un utilisateur peut toujours lire et écrire des fichiers, démarrer des processus, faire des demandes réseau, réécrire les appels d’outils et les invites, refuser un appel d’outil, approuver un qui demanderait autrement, et dessiner dans l’interface, tout avec les permissions de cet utilisateur.
• Les règles de refus et vos hooks gérés ont la priorité. Là où la garde se charge, le mod d’un utilisateur ne peut pas approuver un appel qu’une règle deny refuse, quel que soit le fichier de paramètres qui contient la règle. Un bloc d’un hook PreToolUse dans les paramètres gérés est aussi final. Les deux s’appliquent aux appels d’outils de Claude. Aucun ne s’applique aux appels $.fs et $.process propres à un mod : avec Read(.env) refusé, un mod peut toujours lire ce fichier avec $.fs.read ou démarrer un programme qui le fait. Pour limiter ces appels, empêchez le mod de se charger ou accrochez l’appel dans un mod de politique.
• Les autres vérifications de permission peuvent être contournées. Le mod d’un utilisateur qui approuve les appels d’outils peut approuver un appel qu’une règle ask demanderait, ou qu’un hook PreToolUse en dehors des paramètres gérés a bloqué. En mode auto, un appel que le mod approuve s’exécute sans vérification de classificateur.

​

Savoir quels contrôles s’appliquent toujours

• Les hooks de paramètres continuent de fonctionner. Les hooks de commande, HTTP, d’invite, et d’agent dans les fichiers de paramètres et dans le hooks/hooks.json des plugins s’exécutent comme avant, aux côtés des mods. Rien à leur sujet n’est déprécié.
• Les règles de refus ont la priorité là où la garde se charge. Le mod d’un utilisateur ne peut pas approuver un appel qu’une règle deny refuse, sauf si vous définissez allowModsToOverrideDenyRules.
• Les hooks gérés s’exécutent en premier. Un hook PreToolUse dans les paramètres gérés s’exécute avant que n’importe quel mod ne voie l’appel d’outil, et son bloc est final. Si un mod réécrit ensuite l’appel, vos hooks gérés s’exécutent à nouveau sur l’appel réécrit, donc un bloc s’applique toujours. Les hooks PreToolUse d’autres fichiers de paramètres et de plugins s’exécutent après le dernier mod, donc un mod qui retourne son propre résultat à la place d’exécuter l’outil les empêche de s’exécuter. Voir L’ordre dans lequel les mods s’exécutent.
• La politique réseau couvre $.http.fetch. Si votre organisation désactive la récupération web, ou si le trafic réseau non essentiel est désactivé pour la session, Claude Code refuse une demande réseau qu’un mod fait avec $.http.fetch. La politique ne couvre pas un programme que le mod démarre avec $.process.run. Ce programme atteint le réseau avec l’accès propre de l’utilisateur.
• Les contrôles de plugin couvrent les mods. Un mod est un plugin, donc les paramètres qui limitent ce que les utilisateurs peuvent installer, comme strictKnownMarketplaces, décident s’il peut être installé du tout.
• Les mods ne peuvent pas changer l’invite de permission. Un mod peut redessiner une grande partie de l’interface de Claude Code, mais pas l’invite de permission, donc il ne peut pas changer ce qu’une invite affiche. Un mod peut toujours approuver ou refuser un appel d’outil avant que l’invite n’apparaisse, comme Savoir ce qui se passe par défaut le décrit.
• Les invites de confiance viennent en premier. Dans une session interactive dans un répertoire que l’utilisateur n’a pas encore approuvé, aucun mod ne se charge jusqu’à ce qu’il réponde à l’invite de confiance.
• --safe-mode désactive les mods installés, y compris les vôtres. Démarrez une session avec claude --safe-mode pour vérifier si un mod a causé un problème.

​

Décider de laisser les mods activés

​

Examiner ce qu’un mod peut faire

claude plugin validate ./some-mod

  ❯ ./register.js hooks: session.start, tool.call, ui.render{component=Pane}
  ❯ ./register.js calls: $.fs.read, $.http.fetch, $.store.set, $.ui.open

​

Choisir le niveau d’autorisation

• allowManagedModsOnly : une option sur la garde intégrée. Les mods des utilisateurs ne se chargent pas, et leurs hooks de paramètres, lignes d’état, et /goal continuent de fonctionner. Arrêter le chargement des mods installés par les utilisateurs liste ce qu’il couvre.
• allowManagedHooksOnly : un paramètre plus large. Seuls les mods de votre organisation et les mods intégrés à Claude Code se chargent. Un mod qu’un utilisateur a installé lui-même ne se charge pas. Le paramètre bloque aussi les hooks dans les fichiers de paramètres propres des utilisateurs. Lisez Ce qui s’exécute sous allowManagedHooksOnly avant de le définir.
• disableAllHooks : le paramètre le plus large. Dans les paramètres gérés, il arrête les mods dans chaque plugin installé, y compris les vôtres, et désactive chaque hook dans les fichiers de paramètres, donc un hook PreToolUse dans vos paramètres gérés ne bloque plus rien. Les lignes d’état personnalisées et /goal cessent aussi de fonctionner. Lisez disableAllHooks avant de le définir.
• disableSideloadFlags : rejette --plugin-dir et --plugin-url au démarrage, donc personne ne charge un mod à partir d’un répertoire, et empêche les mods que Claude écrit pendant une session de se charger. Le paramètre rejette aussi --agents et --mcp-config. Lisez disableSideloadFlags avant de le définir.

​

Définir les options sur la garde intégrée

• L’id a une seule orthographe ici : Claude Code lit les options uniquement sous cc-plugin-sec-default@builtin. prependPlugins accepte aussi sec-default@builtin, et pluginConfigs ne le fait pas.
• Seuls les paramètres gérés comptent : la même entrée dans un fichier de paramètres utilisateur, projet ou local, ou dans un fichier passé avec --settings, ne définit ni ne desserre une option
• La garde doit se charger : si vous définissez prependPlugins, nommez la garde dans la liste. Là où la garde ne se charge pas, aucune option ne s’applique.
• La garde échoue fermée : si la garde ne peut pas lire les paramètres gérés, elle refuse tous les mods des utilisateurs au chargement. Si elle ne peut pas vérifier les règles de refus pour un appel qu’un mod d’utilisateur a approuvé, elle refuse l’appel.

​

Exécuter les mods de votre organisation

​

Installer les mods de votre organisation et définir l’ordre

• Les enabledPlugins gérés définissent le plugin du mod à true
• Les paramètres gérés nomment la place de marché du plugin comme un répertoire sur la machine de l’utilisateur, par chemin absolu. Une entrée extraKnownMarketplaces le fait et enregistre aussi la place de marché pour l’utilisateur.
• La place de marché liste le plugin par un chemin relatif, donc Claude Code le charge sur place à partir de ce répertoire

/opt/acme/claude-plugins/
├── .claude-plugin/
│   └── marketplace.json
└── plugins/
    └── acme-guard/
        ├── .claude-plugin/
        │   └── plugin.json
        └── hooks/
            ├── hooks.json
            └── register.js

{
  "name": "acme-tools",
  "owner": { "name": "Acme" },
  "plugins": [
    { "name": "acme-guard", "source": "./plugins/acme-guard", "description": "Acme policy mod" }
  ]
}

• prependPlugins : votre mod voit chaque événement avant n’importe quel mod d’utilisateur et chaque résultat après. Il peut changer l’événement, le refuser, ou sauter les mods des utilisateurs.
• appendPlugins : votre mod s’exécute après chaque mod d’utilisateur, donc il voit uniquement les événements que ces mods transmettent, sous la forme qu’ils les transmettent

{
  "extraKnownMarketplaces": {
    "acme-tools": {
      "source": { "source": "directory", "path": "/opt/acme/claude-plugins" }
    }
  },
  "enabledPlugins": { "acme-guard@acme-tools": true },
  "prependPlugins": ["acme-guard@acme-tools", "sec-default@builtin"]
}

• extraKnownMarketplaces : nomme le répertoire qui contient la place de marché acme-tools. path est le chemin absolu du répertoire qui contient .claude-plugin/marketplace.json.
• enabledPlugins : active acme-guard pour chaque utilisateur qui reçoit ces paramètres gérés
• prependPlugins : met acme-guard en premier et la garde intégrée en deuxième, tous deux avant n’importe quel mod qu’un utilisateur installe. Claude Code suit l’ordre que vous listez.

• hooks module acme-guard@acme-tools loaded, avec tier prepend : le mod compte comme celui de votre organisation et s’exécute en premier
• La même ligne avec tier user : Claude Code le traite comme un mod d’utilisateur. Une deuxième ligne, prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped, dit que la liste l’a sauté.

• La liste remplace la valeur par défaut : quand vous définissez prependPlugins dans les paramètres gérés, nommez sec-default@builtin dans celle-ci pour garder la garde intégrée. La garde est intégrée et n’a besoin d’aucune entrée enabledPlugins.
• Vos propres ids doivent compter comme les vôtres : dans les paramètres gérés, Claude Code saute un id dont le plugin ne respecte pas les trois conditions pour un mod d’organisation
• Les référentiels ne peuvent pas les définir : Claude Code lit les deux paramètres uniquement à partir des paramètres gérés et jamais à partir du fichier de paramètres d’un référentiel. Un utilisateur peut les définir dans ~/.claude/settings.json pour ordonner uniquement ses propres mods sur une machine sans paramètres gérés, et uniquement quand il n’est pas connecté avec un plan Team ou Enterprise. N’importe où ailleurs, Claude Code ignore les deux clés dans les paramètres utilisateur. Une liste là-bas n’ajoute ni ne supprime la garde intégrée.

​

Appliquer une politique avec un mod de votre côté

// Les méthodes qu'aucun mod d'utilisateur ne peut appeler, chacune orthographiée namespace.method
const BLOCKED_CALLS = ['process.run', 'process.spawn']

export function register(on) {
  // S'exécute chaque fois qu'un autre mod est sur le point de se charger
  on('plugin.register', async ($, e, next) => {
    // Gardez les appels dans le code de ce mod qui sont sur la liste bloquée
    const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
    if (e.tier === 'user' && blocked.length > 0) {
      // Retourner refuse empêche le mod de se charger, et le texte est la raison
      return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
    }
    // Laissez tous les autres mods se charger
    return next(e)
  })

  // Enregistrez chaque appel d'outil, puis laissez-le continuer inchangé
  on('tool.call', async ($, e, next) => {
    $.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
    return next(e)
  })

  // Enregistrez quel mod a écrit un fichier, puis le chemin, entre guillemets car le mod l'a choisi
  on('fs.write', async ($, e, next) => {
    $.ui.log('audit fs.write by ' + next.origin.plugin + ' ' + JSON.stringify(e.path), { to: 'debug' })
    return next(e)
  })
}

• plugin.register : décide si un autre mod se charge. Il refuse un mod d’utilisateur qui appelle une méthode bloquée et transmet tous les autres mods.
• tool.call : écrit une ligne comme audit tool.call Bash dans le journal de débogage pour chaque appel d’outil, et ne change rien
• fs.write : écrit une ligne comme audit fs.write by reader "/tmp/notes.md" pour chaque appel $.fs.write qu’un autre mod fait, et ne change rien. Le nom du mod vient en premier et le chemin est entre guillemets, donc un chemin qu’un mod choisit ne peut pas passer pour un autre champ de la ligne.

• e.tier : où le mod s’exécuterait, l’un de prepend, user, append, ou builtin. Chaque mod qu’une personne installe est user.
• e.uses.calls : les méthodes de l’API des mods que le mod appelle, chacune orthographiée namespace.method comme process.run, sans le $. que claude plugin validate imprime

​

Refuser les mods quand votre vérification échoue

const BLOCKED_CALLS = ['process.run', 'process.spawn']

// La même vérification qu'avant, déplacée dans sa propre fonction
async function checkMod($, e, next) {
  const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
  if (e.tier === 'user' && blocked.length > 0) {
    return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
  }
  return next(e)
}

export function register(on) {
  // Le gestionnaire s'exécute uniquement quand checkMod lève une exception ou dépasse sa limite de temps
  on('plugin.register', checkMod).catch(async ($, e, next) => {
    // Laissez les mods de votre organisation et les mods intégrés se charger
    if (e.tier !== 'user') return next(e)
    // Refusez le mod d'utilisateur qui n'a pas pu être vérifié
    return { refuse: 'Acme policy check failed, so this mod was not loaded' }
  })
}

​

Étapes suivantes

• Sécurité des plugins : ce que n’importe quel plugin peut faire sur la machine d’un utilisateur, et comment en examiner un avant qu’il ne soit installé
• Aperçu des mods : ce qu’est un mod et comment il se compare aux crochets, compétences, et serveurs MCP
• L’ordre dans lequel les mods s’exécutent : comment prependPlugins et appendPlugins s’adaptent aux mods des utilisateurs
• Paramètres et variables d’environnement : chaque paramètre nommé sur cette page dans un tableau