settings.local.json de Claude Code filtra secretos en repositorios públicos: por qué "Don't Ask Again" guarda el comando completo y cómo limpiar un repositorio afectado (2026)

Claude Code lee la configuración de varios archivos. La documentación de configuración de Anthropic describe el archivo local del proyecto como .claude/settings.local.json, para "Ti, solo en este proyecto". Su uso previsto es para sobrescrituras personales en un proyecto y pruebas antes de compartir.

No tienes que crearlo. La documentación dice que Claude Code escribe .claude/settings.local.json "la primera vez que otorgas una aprobación permanente en un aviso de permiso". La documentación de permisos detalla lo que esto significa para los comandos de shell. Cuando eliges la opción que impide que Claude Code vuelva a preguntar y la aprobación se guarda permanentemente, "como para un comando Bash o un dominio WebFetch, Claude Code guarda la regla en .claude/settings.local.json en la raíz del repositorio git".

Dos detalles de la misma página son importantes aquí. Las aprobaciones de Bash duran "Permanentemente por repositorio y comando". Y la regla se aplica "a futuras sesiones en cualquier lugar de ese repositorio, incluidas las sesiones iniciadas en subdirectorios y en worktrees". Una aprobación que diste una vez sigue funcionando, y sigue estando en el archivo, hasta que alguien la elimine.

El informe de Apiiro detalla la secuencia. "Pídele a Claude Code que revise una base de datos o llame a una API, y el comando que propone lleva el secreto de tu archivo de configuración. Pregunta antes de ejecutarlo". El secreto tiene que estar en el comando, porque el comando no puede funcionar sin él.

Luego viene la aprobación. Cuando eliges la opción de no volver a preguntar, Apiiro escribe: "ejecuta el comando y agrega una regla de permiso a .claude/settings.local.json en la carpeta del proyecto, para que no vuelva a preguntar. La regla es la cadena del comando en sí".

Una regla de permiso está destinada a describir lo que Claude Code puede ejecutar. Cuando el comando aprobado tiene una contraseña, token o cadena de conexión escrita en él, la regla almacena ese valor en texto plano.

Apiiro afirma que este es el comportamiento de la herramienta, no una peculiaridad de un modelo: "Este es el comportamiento propio de Claude Code, no del modelo: sucede también con los últimos modelos de Anthropic, y lo reprodujimos con Opus 5.5 y Fable 5.1".

Claude Code intenta mantener el archivo fuera de git. La documentación de configuración dice que "La primera vez que Claude Code escribe el archivo en un repositorio git que aún no lo ignora, agrega **/.claude/settings.local.json a tu archivo global de exclusiones de git, para que el archivo se mantenga fuera de tus commits en cada repositorio".

La palabra clave es global. Esa exclusión vive en tu configuración de git en tu máquina, no en el repositorio. Apiiro describe la brecha: "Eso cubre el caso común. No cubre una carpeta que se convierte en repositorio más tarde, un clon en otra máquina o un archivo que alguien ya commiteó". Y: "La regla nunca entra en el .gitignore del propio repositorio, por lo que nada viaja con el proyecto para protegerlo".

También hay una excepción documentada para los archivos que creaste tú mismo. La tabla de configuración dice que Claude Code "lo mantiene fuera de git cuando crea el archivo; si lo creas a mano, agrégalo tú mismo a .gitignore".

Una vez que el archivo es rastreado (tracked), Claude Code cambia la forma en que lo trata, pero sigue escribiendo en él. La documentación de permisos dice: "Cuando el archivo es rastreado en git, o .claude es un symlink, Claude Code lo trata como suministrado por el repositorio y retiene sus reglas hasta que confíes en la carpeta". Apiiro agrega que no se le informa esto al usuario, "y la siguiente aprobación se añade al archivo rastreado".

Apiiro también rastreó quién commiteó el archivo: "En 539 de los 1,105 repositorios con un secreto real que rastreamos, un commit co-autoreado por Claude cambió el archivo". Su explicación es que las instrucciones de commit de Claude Code mencionan archivos como .env y credentials.json, pero "su propio archivo de configuración no está en esa lista".

Las cifras provienen de una búsqueda de código y commits de solo lectura en GitHub en ramas predeterminadas, realizada del 1 al 3 de noviembre de 2026. Apiiro afirma que no probó ninguna credencial: "No se usó ni probó ninguna credencial, y no se contactó a ningún host".

Los recuentos principales:

• El archivo en sí. "De 104,185 copias públicas de este archivo en GitHub, 1,122 contienen un secreto real".
• Secretos distintos en copias actuales. "Juntos contienen 1,379 secretos distintos: 636 claves de proveedores y 743 contraseñas o tokens para hosts públicos".
• Acceso a bases de datos. Apiiro contó 379 contraseñas de bases de datos y 122 claves de service-role de Supabase, además de 103 tokens de cuenta de Supabase.
• Inicios de sesión en servidores. "43 credenciales SSH para servidores públicos, algunas de ellas una contraseña root en un comando sshpass".
• Organizaciones. "63 organizaciones tienen un secreto real en una lista de permitidos pública". Apiiro dice que la mayoría de los secretos pertenecen a desarrolladores individuales.

Dos hallazgos explican por qué borrar el archivo hoy no es suficiente. Primero, los archivos tienden a permanecer mucho tiempo: "En el repositorio promedio con un secreto real, el archivo se commiteó por primera vez 217 días antes de eso". Segundo, el historial los conserva: "Versiones anteriores del archivo contienen 734 secretos reales, en 509 repositorios, que no aparecen en ninguna copia actual, generalmente porque el archivo fue eliminado".

Los archivos más grandes contienen más. Apiiro escribe: "Uno de cada diez archivos de más de 8 KB contiene un secreto real, frente a menos de uno de cada 500 de menos de 500 bytes".

Podrías esperar que un escáner de secretos detecte esto. Apiiro ejecutó gitleaks y TruffleHog en cada archivo. "De los 1,122 archivos con un secreto real, gitleaks marcó 564 y TruffleHog 643; 215 no fueron marcados por ninguno".

La razón es la forma del secreto. Los escáneres buscan formatos de clave conocidos. Una contraseña escrita después de PGPASSWORD=, sshpass -p o mysql -p parece una palabra ordinaria en una línea de comandos ordinaria. El resumen de Apiiro: "La brecha son las contraseñas dentro de los comandos".

Esta es la parte de la investigación que importa más allá de los permisos. Apiiro escribe: "El mismo patrón de contraseña-en-un-comando aparece dondequiera que un agente registre lo que ejecutó: transcripciones, archivos de memoria, notas de traspaso, y un escáner ajustado a formatos de clave lo pasa por alto en todos ellos".

Su tabla de otros archivos incluye:

• .claude/settings.json compartido. De las 76,011 copias públicas revisadas, 298 archivos tenían un secreto real. Los equipos commitean este archivo a propósito.
• Transcripciones de chat de agentes guardadas en repositorios. 2,523 revisadas, 120 archivos en 87 repositorios.
• Archivos de memoria de agentes (MEMORY.md y similares). 1,200 revisados, 9 repositorios.
• Notas de traspaso (handoff) y despliegue. 2,095 revisadas, 33 archivos. Apiiro agrega: "Un tercio de las notas de traspaso con un secreto fueron escritas por el propio agente".

El recuento de archivos de memoria es pequeño, pero el patrón es el mismo. Cualquier cosa que un agente anote sobre lo que hizo puede llevar lo que sea que estuviera en el comando. Si mantienes el contexto del proyecto en archivos que un agente mantiene, esos archivos merecen el mismo cuidado que el archivo de configuración.

Por defecto, Claude Code almacena las transcripciones de las sesiones en tu directorio de inicio, bajo ~/.claude/projects. Nuestra guía para encontrar el historial de sesiones de Claude Code cubre dónde viven y cuánto tiempo se conservan. El recuento de transcripciones de Apiiro cubre exportaciones de varias herramientas que las personas guardaron en repositorios.

La mayoría de las copias nunca llegan a GitHub, y Apiiro argumenta que eso no las hace seguras. "La lista de permitidos es JSON plano en la misma ruta en cada proyecto, y la mayoría de los secretos en ella están junto al host que abren". También señala que el archivo puede salir sin git, "en un paquete npm publicado, una imagen de Docker construida con un comando copy, un archivo zip o una carpeta sincronizada".

Si trabajas en varios checkouts de un mismo repositorio, el archivo se encuentra en un solo lugar. La documentación dice que en un worktree, Claude Code "usa el archivo en la raíz del checkout principal". Nuestra guía sobre si los worktrees de Claude Code comparten memoria explica qué más se comparte entre worktrees.

Apiiro afirma que compartió la investigación con Anthropic antes de la publicación. En una actualización con fecha del 8 de noviembre, Apiiro informa que el responsable de Claude Code en Anthropic respondió en Hacker News el 7 de noviembre.

Según la actualización de Apiiro, escribió que el equipo está "investigando qué podemos hacer para prevenir esto", y mencionó enfoques que planea prototipar, "asegurándose de que el modo auto detecte esto, incorporando un escaneo básico de secretos". Apiiro también informa que, en su opinión, las copias expuestas fueron creadas manualmente y registradas, y que recomendó el modo auto sobre las reglas de permiso y el escaneo de secretos que ofrecen GitHub y otros hosts.

A partir de las versiones de Claude Code publicadas hasta el 10 de noviembre de 2026, las notas de la versión no describen un cambio en cómo se guardan las aprobaciones. Trata esto como un problema abierto y revisa el registro de cambios (changelog) antes de confiar en cualquier solución.

Eliminar el archivo y commitear la eliminación. Elimina la copia actual. No elimina el historial, los forks o los clones, que es donde Apiiro encontró 734 secretos que no aparecen en ninguna copia actual.

Asumir que la exclusión global protege cada máquina. Protege la máquina donde Claude Code la escribió. Un nuevo clon, un ejecutor de CI o una carpeta que se convirtió en repositorio más tarde no la tienen.

Confiar solo en un escáner de secretos. Ambos escáneres que Apiiro probó pasaron por alto una gran proporción de archivos, porque las contraseñas dentro de los comandos no parecen claves.

Aprobar el mismo comando largo una y otra vez. Cada aprobación permanente agrega una regla literal, y Apiiro encontró que los archivos más grandes tienen muchas más probabilidades de contener un secreto.

Paso 1: Encontrar cada copia

Busca en tu organización de GitHub .claude/settings.local.json y .claude/settings.json. Luego revisa el historial de git de cada repositorio en busca del archivo, incluso si ya no existe hoy. En tu propia máquina, busca cada copia y lee su lista de permitidos. Dentro de Claude Code, /permissions enumera tus reglas y el archivo de configuración del que proviene cada una.

Paso 2: Rotar antes de eliminar

El orden de Apiiro es "rotar primero, limpiar después". Cualquier credencial que haya estado alguna vez en el archivo, en cualquier commit, debe tratarse como expuesta. Eliminar el archivo no borra el historial, los forks ni los clones.

Paso 3: Dejar de rastrear el archivo y proteger el repositorio

Si el archivo está siendo rastreado, Apiiro recomienda dejar de rastrearlo con git rm --cached .claude/settings.local.json y agregarlo al propio .gitignore del repositorio. De esa manera, la protección viaja con el proyecto, no solo con tu máquina.

Paso 4: Cambiar la forma de aprobar

Elimina cada regla que contenga un secreto, incluso en archivos que nunca fueron commiteados. Luego deja de escribir secretos en los comandos. Haz referencia a ellos por nombre de variable, para que la regla registre el nombre y no el valor. Aprueba patrones en lugar de comandos literales: el ejemplo de la documentación Bash(npm run *) coincide con npm run build y npm run test --watch. Ten cuidado con qué tan amplio es un patrón, porque la documentación señala que todo lo que esté antes del primer * es lo que limita la regla.

Paso 5: Tratar los archivos del agente como sensibles

Agrega .claude/, transcripciones guardadas, notas de traspaso y archivos de memoria del agente a tu escaneo de secretos de pre-commit y CI, incluyendo el historial. Asegúrate de que el escáner busque contraseñas dentro de los comandos, no solo formatos de clave.

El hallazgo de Apiiro se reduce a un hábito: un agente anota lo que hizo, y lo que sea que hayas escrito en el comando se va con ello. Los archivos de configuración, las transcripciones y los archivos de memoria registran el trabajo. En cada uno de ellos, lo que sea que estuviera en el comando puede terminar registrado junto con el trabajo.

MemoryLake es una capa de memoria para el contexto del proyecto que deseas que tenga un asistente, como qué base de datos usa un servicio, dónde vive el entorno de staging y qué comandos ejecuta el equipo, disponible para los asistentes que conectes, como ChatGPT, Claude Code y Codex.

Tú mismo escribes las entradas, con tus propias palabras. No se lee nada de, ni se escribe en, ni se elimina de tu carpeta .claude, tus archivos de configuración, tus transcripciones de sesión, tu auto memoria, tus repositorios o el almacenamiento de cualquier proveedor. Las reglas de permiso de Claude Code funcionan de la manera que Anthropic describe, y aún necesitas limpiar el archivo de configuración como se describió anteriormente.

Paso 1: Crear una clave de API

Inicia sesión y genera una clave desde el panel de control. Almacénala como lo harías con cualquier otra credencial, fuera de tus repositorios.

Paso 2: Sube tus primeras memorias

Escribe el contexto, no las credenciales: el nombre de la variable de entorno que espera un script, el host en el que se ejecuta un servicio, los pasos que sigue tu equipo para rotar una clave. Un hecho por entrada, y nunca una contraseña o token.

Paso 3: Conecta tu IA y agentes

Conecta Claude Code y cualquier otro asistente que uses. Pueden recurrir al mismo contexto escrito, mientras los secretos permanecen en tu gestor de secretos.

La primera diferencia es una línea clara entre contexto y credenciales. El conocimiento del proyecto vive en entradas que tú escribiste, y los valores que abren sistemas viven en algún lugar construido para ellos.

La segunda es que hay menos razones para pegar secretos en una sesión. Cuando el asistente ya sabe qué variable contiene la cadena de conexión, el comando puede hacer referencia a la variable.

Lee el comando antes de aprobarlo. Especialmente cuando se conecta a una base de datos o a un servidor.

Aprueba patrones, no comandos literales. Una regla como Bash(npm run *) no lleva argumentos que escribiste una vez.

Mantén los secretos en variables. La regla entonces registra el nombre de la variable.

Agrega el archivo al .gitignore del propio repositorio. No confíes en una exclusión global que solo tiene tu máquina.

Revisa la lista de permitidos regularmente. /permissions muestra cada regla y de dónde proviene.

Escanea los archivos del agente y el historial. Configuraciones, transcripciones, notas de traspaso y archivos de memoria pueden llevar comandos.

Rota ante cualquier duda. El historial y los forks conservan lo que eliminas.

Cuando eliges la opción para que Claude Code deje de preguntar sobre un comando de shell, Claude Code guarda ese comando como una regla de permiso en .claude/settings.local.json. Si el comando contenía una contraseña o token, la regla también lo contiene. Claude Code agrega el archivo a tus exclusiones globales de git cuando lo crea, pero esa protección no viaja con el repositorio, y Apiiro encontró 1,122 copias públicas del archivo con un secreto real, con 2,539 secretos distintos en todos los archivos de agentes que revisó.

Revisa tus repositorios e historial en busca del archivo, rota cualquier cosa que haya contenido alguna vez, deja de rastrearlo y agrégalo al .gitignore del repositorio, y cambia la forma en que apruebas los comandos. Luego, trata cada archivo que escriba un agente, incluidos los archivos de memoria, como algo que puede contener un secreto.