Guías prácticas para trabajar con agentes de IA
Claude Code lee sus ajustes de cuatro ficheros, y cada uno vale para gente distinta: solo tú, todo el que trabaje en el proyecto o toda tu organización. Cuando dos ficheros ponen valores distintos a la misma clave, el del proyecto se impone al tuyo de usuario, tu fichero local del proyecto se impone al del equipo, y lo que reparte tu organización se impone a todos.
6 min de lectura publicado el 27 oct 2026
Tu caso. Cambias algo de Claude Code —el modelo con el que arranca, una orden que puede ejecutar sin preguntarte— y en un proyecto no hace caso. O lo cambias en el repositorio y a tus compañeros no les llega. Las dos cosas suelen tener la misma causa: el ajuste está guardado en un fichero que no es el que manda en ese sitio.
Qué lo decide. Los ajustes son claves de ficheros JSON, y el fichero donde guardas una clave decide a quién le afecta. Claude Code lee cuatro, más los que reparta tu organización: V
~/.claude/settings.json, el de usuario, que vale para ti en todos los proyectos de esa máquina;.claude/settings.json dentro del proyecto, el compartido, que vale para todo el que trabaje en esa carpeta, y para tus compañeros cuando lo subes al repositorio;.claude/settings.local.json dentro del proyecto, el local, que vale solo para ti y solo en ese proyecto;managed-settings.json, una política del sistema o desde la consola de claude.ai, y que valen para todos aquellos a quienes se los aplique.Cómo mirar los tuyos. Hay dos sitios, y conviene mirarlos en este orden, porque el primero dice qué ficheros se han leído y el segundo qué parte de ellos se ha descartado: V
/status, dentro de una sesión. En la pestaña Status, la línea Setting sources lista cada fichero de ajustes que se ha cargado, y si tu organización te aplica uno gestionado dice entre paréntesis cómo te ha llegado. No dice qué fichero ha puesto cada clave.claude doctor, en el terminal. Lista las entradas que Claude Code ha rechazado, por ejemplo una regla de permisos mal escrita —una línea que decide si Claude puede ejecutar una orden sin preguntar—, que se ignora mientras el resto del fichero sigue valiendo.Qué hace de fábrica. Instalar Claude Code no crea ningún fichero de ajustes, así que sin tocar nada todo va con sus valores por defecto. El de usuario lo crea Claude Code la primera vez que cambias en /config una opción que se guarda ahí, como el tema. El local lo crea la primera vez que, ante una petición de permiso, eliges que no vuelva a preguntar por esa orden: la aprobación se guarda en él como regla de permiso. Al crearlo, lo deja fuera de git, para que no acabe en tus commits, los puntos de guardado del repositorio. V
Qué pasa si pones la misma clave en dos sitios. Gana el nivel más alto que la tenga. De más a menos: V
--settings al lanzar claude, solo para esa sesión;Un caso concreto: tú pones un modelo en tu fichero de usuario y el equipo pone otro en el compartido del proyecto. En ese proyecto arrancas con el del equipo, y en los demás con el tuyo. Para recuperar el tuyo solo ahí, escríbelo en el .claude/settings.local.json de ese proyecto, que está un nivel por encima y no cambia nada a tus compañeros. Si lo pone tu organización, no hay fichero tuyo que lo cambie, ni siquiera --settings: /status te dice de dónde viene, y quien lo puede cambiar es el administrador. V
Hay tres excepciones a ese orden. Las listas, como la de órdenes permitidas, no se sustituyen: se suman las de todos los ficheros, así que las reglas que pone tu organización siguen valiendo junto a las tuyas. Para unas pocas claves de seguridad, Claude Code respeta el valor más estricto aunque venga de un nivel más bajo que el de la organización. Y las variables de entorno no son un nivel más: cada una se lleva con su clave a su manera, y por ejemplo ANTHROPIC_MODEL exportada en tu terminal se impone a la clave model de cualquier fichero. V
Lo que un repositorio no puede ponerte. Algunas claves no tienen efecto desde el fichero compartido del proyecto. Los modos de permisos que dejan a Claude actuar sin preguntar, auto y bypassPermissions, solo se aplican desde tu fichero de usuario o desde los gestionados. Y las reglas que permiten órdenes, escritas en un fichero que viene con el repositorio, esperan a que cada persona marque esa carpeta como de confianza; las que prohíben o piden confirmación se aplican desde el primer momento. V Para ti significa que clonar un repositorio ajeno no le da a ese repositorio permiso para que Claude ejecute cosas sin preguntarte, pero si aceptas la confianza de la carpeta, sus permisos pasan a valer. Mira su .claude/settings.json antes de aceptarla. I El orden en que se aplican esas reglas entre sí lo contamos en la guía de permisos.
model y effortLevel. Para cambiarlas en mitad de una sesión, usa /model y /effort. Cambiar de modelo hace que la siguiente petición vuelva a leer toda la conversación sin caché, porque cada modelo tiene la suya..claude/settings.local.json en la raíz del repositorio, y una aprobación que des vale para todo el repositorio. Hasta la versión 2.1.211 lo guardaba en la carpeta donde lo abrías; sigue leyendo un fichero que dejara ahí una versión anterior, y si los dos ponen la misma clave, gana el de la raíz..claude/settings.json en la carpeta donde abres la sesión. Para que se aplique el de la raíz del repositorio, abre la sesión ahí.bypassPermissions tenía efecto desde cualquier fichero, también desde el compartido de un repositorio. Si trabajas con una versión anterior, actualiza.~/.claude.json lo escribe Claude Code para sí: guarda tu cuenta, la configuración de los servidores MCP, los que le añaden herramientas a Claude, y qué carpetas has marcado como de confianza.