Claude Code para un equipo, qué se comparte, qué se impone y qué se hace cumplir

Sesenta personas usan Claude Code en cinco repositorios y cada una lo configuró a su manera: algunas aprueban cada comando, otras permitieron cualquier comando de shell y unas pocas dejaron que Claude lea archivos .env con credenciales de producción. Las convenciones del proyecto viven en notas personales, así que Claude se comporta distinto según quién lo abra. El problema no es la herramienta: es dónde vive cada regla.

Cuatro lugares, cuatro alcances

Archivo	A quién afecta	Para qué
Configuración administrada (managed settings)	toda la organización donde se despliega	políticas de seguridad y cumplimiento que nadie puede pisar
.claude/settings.json en el repo	todo el que trabaja en el proyecto, si se versiona	permisos, hooks y plugins del equipo
.claude/settings.local.json	vos, en ese proyecto	excepciones personales; queda fuera de git
~/.claude/settings.json	vos, en todos tus proyectos	preferencias personales

A eso se suma el CLAUDE.md del proyecto, versionado en el repo, con las convenciones que Claude tiene que conocer: cómo se corren los tests, la estructura, las reglas de estilo.

La precedencia de configuración (settings precedence), de mayor a menor, es: administrada, línea de comandos, local del proyecto, compartida del proyecto y usuario. Una clave de un nivel más alto pisa la misma clave más abajo. Nada en los archivos de una persona, ni siquiera un flag de la sesión, pisa una clave administrada. Las listas, como las reglas de permisos, se combinan entre niveles en lugar de reemplazarse.

Contexto no es control

CLAUDE.md es contexto que el modelo lee al empezar cada sesión y suele seguir, pero no es configuración que se haga cumplir. Una línea que diga “NUNCA edites migraciones ya aplicadas” se va a respetar casi siempre, y en una sesión larga de refactorización puede no respetarse.

Para que una acción quede bloqueada siempre, sin depender de lo que decida el modelo, se usa un control determinista:

• Reglas de denegación (deny rules) en los permisos, por ejemplo para leer .env o editar una carpeta.
• Un hook previo a la herramienta (PreToolUse hook), que revisa cada llamada antes de que se ejecute y la bloquea si viola la política.

Si la regla es del equipo, va en la configuración compartida del proyecto. Si es de la organización y nadie la puede desactivar, va en la administrada.

Un reparto razonable

• Organización: reglas deny para secretos y rutas sensibles, límites de modelos permitidos, políticas que no se negocian.
• Proyecto: permisos para los comandos habituales (tests, lint), hooks del equipo y un CLAUDE.md con las convenciones.
• Persona: tema, editor, modelo por defecto, aprobaciones propias para ese repo.

Las trampas típicas

• Dar a todos el modo que omite los permisos (bypassPermissions) “para que las diferencias dejen de importar”. Además, ese modo no se activa desde la configuración del proyecto.
• Publicar un fragmento en la wiki y pedir que cada uno lo pegue en su configuración personal: no se versiona ni se puede verificar.
• Poner reglas de seguridad en settings.local.json: es personal y queda fuera del repo.
• Reescribir la regla de CLAUDE.md en mayúsculas o repetirla en cada carpeta.
• Confiar en la memoria automática para que Claude “recuerde” el incidente.

En el examen

Si el escenario describe configuraciones distintas por persona, buscá la combinación: configuración compartida y CLAUDE.md versionados en el repo para lo del equipo, y configuración administrada para lo que nadie puede desactivar. Si una regla escrita en CLAUDE.md se rompió, la respuesta es un control determinista (reglas deny o un hook PreToolUse) en la configuración compartida, no una redacción más enfática.