Managed settings de Claude Code: imponer un plugin y su marketplace en las máquinas del equipo

Hola, bienvenido. Llegamos a la última lección del curso, que forma por sí sola el último bloque opcional: imponer el plugin team y su marketplace en las máquinas del equipo con managed settings. Vamos a escribir el archivo gestionado, a ver qué cambia para Aitor cuando su portátil lo recibe y a preparar el alta de una máquina gestionada para que el plugin funcione desde la primera sesión. Y al final vamos a dejar tu máquina limpia de todo lo que el curso ha instalado fuera de los repos.

Si tu equipo no gestiona sus máquinas, porque cada persona instala y configura la suya, puedes saltarte esta lección hasta la limpieza del final: el plugin, los 2 comandos del README y el hook que comprueba el repo funcionan igual sin managed settings. Es la parte del curso pensada para organizaciones con cuenta Team o Enterprise. Aun así, el archivo gestionado que vamos a usar es local, y lo puedes probar en tu máquina con cualquier plan. Ten en cuenta que, con el archivo en la máquina, Claude Code carga también el guard de los mods de la lección anterior, sec-default@builtin, aunque tu plan sea Pro o Max.

Hasta ahora, el plugin llega a cada repo con los 2 comandos del README, y el hook avisa al abrir la sesión de lo que falta. Pero todo eso depende de que cada persona quiera usarlo. Cualquiera puede desactivar el plugin con un false en su settings.local.json, y nada le impide registrar otro marketplace o darse en su configuración local permisos que el repo no da. Para la mayoría de equipos es suficiente: el plugin es la primera barrera, y lo que tiene que cumplirse siempre lo comprueban git y la QA antes del merge, como dijimos en la primera lección.

Compensa cuando alguien ya gestiona las máquinas del equipo y la organización necesita garantías: que el plugin esté siempre activo, que no se instale nada desde un marketplace que nadie ha aprobado y que nadie relaje en local las reglas deny. Esas máquinas se gestionan con un MDM, que es una herramienta de gestión de dispositivos como Jamf o Intune, o con Ansible en los equipos Linux. Managed settings es la configuración que la organización despliega en cada máquina, y Claude Code la aplica por encima de todos los demás ámbitos. Ni la configuración de usuario, ni la del proyecto, ni la local, ni --settings la sobrescriben. Una regla deny, además, se puede relajar de 2 formas: con otra configuración en local o con un mod que apruebe la llamada que la regla deniega, y la segunda solo la impide el guard de los mods, que se carga con managed settings o con una sesión de Team o Enterprise. Como vimos en la lección anterior, el guard solo protege las reglas: si un hook como guard.sh ha bloqueado la llamada antes de que Claude Code evaluara las reglas, o si la organización activa allowModsToOverrideDenyRules, un mod sigue pudiendo aprobarla.

La lección Configurar Claude Code en un proyecto con .claude y settings.json↗ (se abre en una pestaña nueva) del curso de Claude Code nombra este ámbito en su tabla de prioridades. En esta lección vamos a usarlo.