Administrar mods para su organización

• Mantenga los mods propios de los usuarios fuera, con o sin mods propios: Detenga la carga de mods instalados por usuarios
• Vea qué obtienen sus usuarios cuando no cambia nada: Sepa qué sucede de forma predeterminada
• Deje los mods activados con otras limitaciones: Elija cuánto permitir

​

Detenga la carga de mods instalados por usuarios

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

• Ningún mod que traiga un usuario se carga: eso cubre un mod en un plugin que el usuario instaló, un mod cargado con --plugin-dir, y un mod que Claude escribió durante una sesión
• Los mods de su organización aún se cargan: un mod que cuenta como de su organización no se verifica. Todos los demás mods cuentan como de un usuario y no se cargan. Eso incluye un mod en un plugin que habilita desde un marketplace remoto de GitHub u otro, y uno que su organización activa para sus miembros en claude.ai. Si ninguno cuenta como suyo, no se carga ningún mod instalado.
• Los usuarios no pueden deshacerlo: el guard lee la opción solo de la configuración administrada, por lo que la misma entrada en un archivo de configuración de usuario, proyecto o local, o en un archivo pasado con --settings, no cambia nada
• Un archivo o política MDM cubre cada proveedor: cuando entrega la opción como archivo o a través de MDM, funciona de la misma manera en Amazon Bedrock, Agent Platform de Google Cloud y Microsoft Foundry. Para la entrega desde la consola de administrador de claude.ai, consulte Disponibilidad de plataforma
• Las personalizaciones de otros usuarios siguen funcionando: sus hooks en archivos de configuración, líneas de estado y /goal no se ven afectados
• Los mods integrados siguen ejecutándose: los mods integrados en Claude Code, como el soporte de AGENTS.md, cada uno tiene su propio interruptor

​

Sepa qué sucede de forma predeterminada

• Los mods están activados. Un usuario puede instalar un plugin que contenga un mod desde cualquier marketplace que su configuración de plugins permita, o cargar uno desde un directorio con --plugin-dir.
• Un guard integrado se ejecuta primero. Claude Code carga un mod integrado llamado sec-default@builtin antes de cada mod que instala un usuario. Los usuarios no pueden desactivarlo. /plugin y el registro de depuración lo enumeran como cc-plugin-sec-default. El guard se carga cuando cualquiera de estos es verdadero:
  • La máquina tiene configuración administrada
  • El usuario ha iniciado sesión en Claude Code con un plan de Team o Enterprise
  Un usuario que se autentica con una clave API, o a través de Amazon Bedrock, Agent Platform de Google Cloud o Microsoft Foundry, obtiene el guard solo en una máquina que tiene configuración administrada.
• El guard protege lo que usted administra. El mod de un usuario no puede cambiar lo que sus hooks administrados reciben o deciden, el prompt del sistema, su CLAUDE.md administrado y otras instrucciones administradas, lo que cualquier mod lee como configuración, o las herramientas y descripciones de sus servidores MCP administrados.
• Todo lo demás está permitido. El guard no agrega otras restricciones. El mod de un usuario aún puede leer y escribir archivos, iniciar procesos, hacer solicitudes de red, reescribir llamadas de herramientas y prompts, negar una llamada de herramienta, aprobar una que de otro modo solicitaría, y dibujar en la interfaz, todo con los permisos de ese usuario.
• Las reglas de negación y sus hooks administrados tienen prioridad. Donde se carga el guard, el mod de un usuario no puede aprobar una llamada que una regla deny rechaza, cualquiera que sea el archivo de configuración que contenga la regla. Un bloqueo de un hook PreToolUse en la configuración administrada también es final. Ambos se aplican a las llamadas de herramientas de Claude. Ninguno se aplica a las llamadas propias de $.fs y $.process de un mod: con Read(.env) denegado, un mod aún puede leer ese archivo con $.fs.read o iniciar un programa que lo haga. Para limitar esas llamadas, evite que el mod se cargue o enganche la llamada en un mod de política.
• Otras comprobaciones de permisos pueden ser anuladas. El mod de un usuario que aprueba llamadas de herramientas puede aprobar una llamada que una regla ask solicitaría, o que un hook PreToolUse fuera de la configuración administrada bloqueó. En modo automático, una llamada que el mod aprueba se ejecuta sin una comprobación de clasificador.

​

Sepa qué controles aún se aplican

• Los hooks de configuración siguen funcionando. Los hooks de comando, HTTP, prompt y agente en archivos de configuración y en hooks/hooks.json de plugins se ejecutan como antes, junto con mods. Nada sobre ellos está deprecado.
• Las reglas de negación tienen prioridad donde se carga el guard. El mod de un usuario no puede aprobar una llamada que una regla deny rechaza, a menos que establezca allowModsToOverrideDenyRules.
• Los hooks administrados se ejecutan primero. Un hook PreToolUse en la configuración administrada se ejecuta antes de que cualquier mod vea la llamada de herramienta, y su bloqueo es final. Si un mod luego reescribe la llamada, sus hooks administrados se ejecutan nuevamente en la llamada reescrita, por lo que un bloqueo aún se aplica. Los hooks PreToolUse de otros archivos de configuración y de plugins se ejecutan después del último mod, por lo que un mod que devuelve su propio resultado en lugar de ejecutar la herramienta evita que se ejecuten. Consulte El orden en que se ejecutan los mods.
• La política de red cubre $.http.fetch. Si su organización desactiva la obtención web, o el tráfico de red no esencial se desactiva para la sesión, Claude Code rechaza una solicitud de red que un mod hace con $.http.fetch. La política no cubre un programa que el mod inicia con $.process.run. Ese programa alcanza la red con el acceso propio del usuario.
• Los controles de plugins cubren mods. Un mod es un plugin, por lo que la configuración que restringe lo que los usuarios pueden instalar, como strictKnownMarketplaces, decide si puede instalarse en absoluto.
• Los mods no pueden cambiar el prompt de permiso. Un mod puede cambiar el estilo de gran parte de la interfaz de Claude Code, pero no el prompt de permiso, por lo que no puede cambiar lo que muestra un prompt. Un mod aún puede aprobar o negar una llamada de herramienta antes de que aparezca el prompt, como describe Sepa qué sucede de forma predeterminada.
• Los prompts de confianza vienen primero. En una sesión interactiva en un directorio que el usuario aún no ha confiado, ningún mod se carga hasta que responda el prompt de confianza.
• --safe-mode desactiva los mods instalados, incluidos los suyos. Inicie una sesión con claude --safe-mode para verificar si un mod causó un problema.

​

Decida si dejar los mods activados

​

Revise qué puede hacer un mod

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

​

Elija cuánto permitir

• allowManagedModsOnly: una opción en el guard integrado. Los mods propios de los usuarios no se cargan, y sus hooks de configuración, líneas de estado y /goal siguen funcionando. Detenga la carga de mods instalados por usuarios enumera lo que cubre.
• allowManagedHooksOnly: una configuración más amplia. Solo los mods de su organización y los mods integrados en Claude Code se cargan. Un mod que un usuario instaló por sí mismo no. La configuración también bloquea los hooks en los archivos de configuración propios de los usuarios. Lea Lo que se ejecuta bajo allowManagedHooksOnly antes de establecerlo.
• disableAllHooks: la configuración más amplia. En la configuración administrada, detiene los mods en cada plugin instalado, incluidos los suyos, y desactiva cada hook en archivos de configuración, por lo que un hook PreToolUse en su configuración administrada ya no bloquea nada. Las líneas de estado personalizadas y /goal también dejan de funcionar. Lea disableAllHooks antes de establecerlo.
• disableSideloadFlags: rechaza --plugin-dir y --plugin-url al inicio, por lo que nadie carga un mod desde un directorio, y evita que se carguen los mods que Claude escribe durante una sesión. La configuración también rechaza --agents y --mcp-config. Lea disableSideloadFlags antes de establecerlo.

​

Establezca opciones en el guard integrado

• El id tiene una ortografía aquí: Claude Code lee las opciones solo bajo cc-plugin-sec-default@builtin. prependPlugins acepta sec-default@builtin también, y pluginConfigs no.
• Solo la configuración administrada cuenta: la misma entrada en un archivo de configuración de usuario, proyecto o local, o en un archivo pasado con --settings, ni establece una opción ni afloja una
• El guard tiene que cargarse: si establece prependPlugins, nombre el guard en la lista. Donde el guard no se carga, ninguna opción se aplica.
• El guard falla cerrado: si el guard no puede leer la configuración administrada, rechaza cada mod de usuario al cargar. Si no puede verificar las reglas de negación para una llamada que un mod de usuario aprobó, rechaza la llamada.

​

Ejecute los mods propios de su organización

​

Instale los mods de su organización y establezca el orden

• enabledPlugins administrado establece el plugin del mod en true
• La configuración administrada nombra el marketplace del plugin como un directorio en la máquina del usuario, por ruta absoluta. Una entrada extraKnownMarketplaces hace eso y también registra el marketplace para el usuario.
• El marketplace enumera el plugin por una ruta relativa, por lo que Claude Code lo carga en su lugar desde ese directorio

/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: su mod ve cada evento antes que cualquier mod de usuario y cada resultado después. Puede cambiar el evento, rechazarlo u omitir los mods de los usuarios.
• appendPlugins: su mod se ejecuta después de cada mod de usuario, por lo que solo ve los eventos que esos mods pasan, en la forma en que los pasan

{
  "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: nombra el directorio que contiene el marketplace acme-tools. path es la ruta absoluta del directorio que contiene .claude-plugin/marketplace.json.
• enabledPlugins: activa acme-guard para cada usuario que recibe esta configuración administrada
• prependPlugins: pone acme-guard primero y el guard integrado segundo, ambos antes de cualquier mod que instale un usuario. Claude Code sigue el orden que enumera.

• hooks module acme-guard@acme-tools loaded, con tier prepend: el mod cuenta como de su organización y se ejecuta primero
• La misma línea con tier user: Claude Code lo trata como un mod de usuario. Una segunda línea, prependPlugins names acme-guard@acme-tools, which is not an enabled managed plugin with a hooks module; skipped, dice que la lista lo omitió.

• La lista reemplaza el predeterminado: cuando establece prependPlugins en la configuración administrada, nombre sec-default@builtin en ella para mantener el guard integrado. El guard está integrado y no necesita una entrada enabledPlugins.
• Sus propios ids deben contar como suyos: en la configuración administrada, Claude Code omite un id cuyo plugin no cumple las tres condiciones para un mod de una organización
• Los repositorios no pueden establecerlos: Claude Code lee ambas configuraciones de la configuración administrada y nunca de un archivo de configuración de un repositorio. Un usuario puede establecerlos en ~/.claude/settings.json para ordenar solo sus propios mods en una máquina sin configuración administrada, y solo cuando no han iniciado sesión con un plan de Team o Enterprise. En cualquier otro lugar, Claude Code ignora ambas claves en la configuración del usuario. Una lista allí ni agrega ni elimina el guard integrado.

​

Haga cumplir una política con un mod propio

// Los métodos que ningún mod de usuario puede llamar, cada uno deletreado namespace.method
const BLOCKED_CALLS = ['process.run', 'process.spawn']

export function register(on) {
  // Se ejecuta cada vez que otro mod está a punto de cargarse
  on('plugin.register', async ($, e, next) => {
    // Mantenga las llamadas en el código de ese mod que están en la lista bloqueada
    const blocked = e.uses.calls.filter((call) => BLOCKED_CALLS.includes(call))
    if (e.tier === 'user' && blocked.length > 0) {
      // Devolver refuse evita que el mod se cargue, y el texto es la razón
      return { refuse: 'Acme policy: mods may not call ' + blocked.join(', ') }
    }
    // Deje que cada otro mod se cargue
    return next(e)
  })

  // Registre cada llamada de herramienta, luego déjela avanzar sin cambios
  on('tool.call', async ($, e, next) => {
    $.ui.log('audit tool.call ' + e.tool, { to: 'debug' })
    return next(e)
  })

  // Registre qué mod escribió un archivo, luego la ruta, entrecomillada porque el mod la eligió
  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: decide si otro mod se carga. Rechaza un mod de usuario que llama a un método bloqueado y pasa cada otro mod.
• tool.call: escribe una línea como audit tool.call Bash en el registro de depuración para cada llamada de herramienta, y no cambia nada
• fs.write: escribe una línea como audit fs.write by reader "/tmp/notes.md" para cada llamada $.fs.write que hace otro mod, y no cambia nada. El nombre del mod viene primero y la ruta está entrecomillada, por lo que una ruta que un mod elige no puede pasar por otro campo de la línea.

• e.tier: dónde se ejecutaría el mod, uno de prepend, user, append, o builtin. Cada mod que una persona instala es user.
• e.uses.calls: los métodos de la API de mods que llama el mod, cada uno deletreado namespace.method como process.run, sin el $. que claude plugin validate imprime

​

Rechace mods cuando su verificación falla

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

// La misma verificación que antes, movida a una función propia
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) {
  // El controlador se ejecuta solo cuando checkMod lanza o se ejecuta más allá de su límite de tiempo
  on('plugin.register', checkMod).catch(async ($, e, next) => {
    // Deje que los mods de su organización y los mods integrados se carguen
    if (e.tier !== 'user') return next(e)
    // Rechace el mod de usuario que no pudo ser verificado
    return { refuse: 'Acme policy check failed, so this mod was not loaded' }
  })
}

​

Próximos pasos

• Seguridad de plugins: qué puede hacer cualquier plugin en la máquina de un usuario, y cómo revisar uno antes de que se instale
• Descripción general de mods: qué es un mod y cómo se compara con hooks, skills y servidores MCP
• El orden en que se ejecutan los mods: cómo prependPlugins y appendPlugins se ajustan con los mods de los usuarios
• Configuración y variables de entorno: cada configuración nombrada en esta página en una tabla