El botón «don't ask again» de Claude Code dejó contraseñas reales en 1,122 archivos públicos de GitHub

Si usas Claude Code y alguna vez le diste a "Yes, and don't ask again" a un comando que llevaba una contraseña, esa contraseña está escrita en texto plano en un archivo de tu proyecto. Y si ese archivo se subió a GitHub, ya es pública. La empresa de seguridad Apiiro publicó el 5 de noviembre de 2026 una investigación que contó el tamaño del problema: de 104,185 copias públicas de .claude/settings.local.json en GitHub, 1,122 tienen al menos un secreto real. Hay contraseñas de bases de datos de producción, llaves de nube y accesos SSH de root. Si programas con agentes, revisa esto hoy.

Cómo pasa

El mecanismo no es un hackeo ni un error del modelo. Así funciona la herramienta, y está en su documentación oficial. Cuando Claude Code te pide permiso para correr un comando de terminal y eliges "Yes, and don't ask again", guarda ese permiso como una regla allow en .claude/settings.local.json, dentro de la carpeta del proyecto. Según Apiiro, la regla es el texto literal del comando. Si el comando era PGPASSWORD=... psql -h ... o un curl con un header Authorization: Bearer ..., la contraseña o el token quedan copiados tal cual.

Y el comando casi siempre lleva el secreto. Le pides al agente que revise por qué falla el login en staging o que corra una migración, y él toma la cadena de conexión de tu archivo de configuración porque sin ella no puede hacer nada. Apiiro describe lo que todos hemos vivido: después de la décima interrupción de la sesión ya nadie lee el comando completo, y la contraseña es una palabra perdida en una línea larguísima.

Los investigadores dicen que lo reprodujeron con modelos recientes de Anthropic, Opus 5.5 entre ellos, porque el comportamiento es de Claude Code y no del modelo. De los 16 agentes de programación que compararon con su documentación, Claude Code es el único que confirmaron que escribe por defecto el comando aprobado completo en un archivo del proyecto.

Diagrama: cómo una contraseña pasa de un comando aprobado en Claude Code a .claude/settings.local.json y de ahí a un repositorio público, con los pasos para revisarlo y corregirlo

¿Y el gitignore?

Aquí está el punto fino. La documentación de Anthropic dice que la primera vez que Claude Code escribe ese archivo dentro de un repositorio de git que no lo ignora, agrega **/.claude/settings.local.json a tus exclusiones globales de git, es decir, al archivo de ignorados de tu máquina, no al .gitignore del proyecto. La misma página aclara que si creaste el archivo a mano tienes que ignorarlo tú.

Apiiro reconoce que esa protección cubre el caso común, pero señala los huecos: no cubre una carpeta que se convirtió en repo después, un clon del proyecto en otra máquina ni un archivo que ya estaba en un commit. Como la regla nunca llega al .gitignore del repo, nada viaja con el proyecto para protegerlo. Hay un dato incómodo: en 539 de los 1,105 repos con un secreto real que rastrearon, un commit coescrito por Claude modificó ese archivo.

Los números

Apiiro hizo búsquedas de solo lectura en GitHub entre el 1 y el 3 de noviembre de 2026 y descargó cada archivo. Esto encontró:

104,185 copias públicas de .claude/settings.local.json en 103,617 repositorios.
1,122 archivos (1.1%) con al menos un secreto real, que suman 1,379 secretos distintos: 636 llaves con formato de proveedor y 743 contraseñas o tokens junto a un host público.
Más de un tercio abre una base de datos directo: 379 contraseñas de bases de datos y 122 llaves service-role de Supabase. Hay además 103 tokens de cuenta de Supabase, 43 accesos SSH, 42 tokens de GitHub, GitLab y npm, 23 llaves de AWS y 6 llaves privadas.
63 organizaciones afectadas, desde grupos de estudiantes hasta un proveedor de bases de datos con su propia llave de nube con permisos de administración, una startup con la contraseña de su Postgres de producción en Azure y una empresa de TI con la contraseña de dueño de la base de una app de expedientes médicos. Una empresa confirmó que su llave estaba activa.
Contando el historial de git, el .claude/settings.json que los equipos comparten a propósito (298 archivos con secretos de 76,011 revisados) y transcripciones de chats con agentes, el total sube a 2,539 secretos en 1,994 repositorios.

Gráfica de barras: tipos de secretos encontrados en los 1,122 archivos .claude/settings.local.json públicos con secretos reales, encabezados por 379 contraseñas de bases de datos

Dos datos más dicen bastante. Los archivos grandes concentran el riesgo: uno de cada diez archivos de más de 8 KB tiene un secreto, contra menos de uno de cada 500 de los que pesan menos de 500 bytes. Entre más tiempo llevas aprobando sin leer, más se acumula. Y borrar el archivo no basta: versiones anteriores en el historial guardan 734 secretos que ya no aparecen en ninguna copia actual, y 211 forks de 74 repos cargan los mismos secretos.

Ojo con un límite que la propia Apiiro marca: "secreto real" significa que el valor tiene el formato de un proveedor conocido o que apunta a un host público, no que siga funcionando. No usaron ni probaron ninguna credencial.

Por qué los escáneres no lo ven

Esta parte le importa a cualquiera que confíe en el escaneo de secretos de su CI. Apiiro pasó gitleaks y TruffleHog sobre los 104,185 archivos. De los 1,122 con un secreto real, gitleaks marcó 564 y TruffleHog 643, y 215 no los marcó ninguno. La razón: esas herramientas buscan formatos de llave (un prefijo de proveedor y una cadena aleatoria larga). Una contraseña escrita después de PGPASSWORD=, sshpass -p o mysql -p es una palabra normal dentro de un comando normal, y casi siempre se les pasa.

Qué dice Anthropic

Apiiro dice que compartió la investigación con Anthropic antes de publicarla. Ya publicada, Boris Cherny, que dirige Claude Code, escribió en Hacker News que la herramienta "históricamente no ha hecho limpieza de secretos" y que están viendo qué pueden hacer para evitarlo. En ese mismo comentario defendió que el archivo "está hecho para quedarse local", que se ignora en automático cuando Claude lo crea y que, en estos casos, los archivos se crearon a mano y se subieron. Recomendó usar el modo automático en lugar de mantener listas de permisos y activar el escaneo de secretos del proveedor de git.

El problema no es nuevo. Usuarios de Claude Code lo reportan desde agosto de 2025: en el issue #5544 alguien describió exactamente este comportamiento, con pasos para reproducirlo. Ese reporte se cerró solo por inactividad en enero de 2026, sin respuesta del equipo.

Qué hacer

Estas recomendaciones salen de Apiiro y de la documentación de Claude Code. No lo probé en un repo propio.

Busca el archivo en tus repos y en tu organización de GitHub: .claude/settings.local.json y también .claude/settings.json.
Revisa el historial aunque hoy no esté: git log --all --oneline -- .claude/settings.local.json. Si el historial lo tiene, también lo tienen los forks y los clones.
Sácalo del repo con git rm --cached .claude/settings.local.json y agrégalo al .gitignore del proyecto, no solo al global.
Rota primero, limpia después. Toda credencial que haya estado en ese archivo se cambia. Borrar el archivo no la desaparece de internet.
Abre el archivo aunque nunca lo hayas subido y borra cada regla allow que lleve una contraseña, un token o una llave. Malware como el gusano Shai-Hulud de npm ya buscaba secretos en discos de desarrolladores, según la misma investigación.
Cambia el hábito: pasa los secretos como variables ($DB_URL) desde tu gestor de secretos, para que la regla guarde la variable y no el valor, y aprueba patrones como Bash(npm run:*) en vez de comandos literales.
Si llevas seguridad en un equipo: trata .claude/, .cursor/, .gemini/ y los archivos de memoria de los agentes igual que un .env, y configura el escáner para que detecte contraseñas dentro de comandos.

Mi lectura

Las dos versiones tienen parte de razón. Anthropic sí intenta que el archivo no se suba, y nadie publica una llave a propósito. Pero el diseño guarda el secreto en texto plano dentro de la carpeta del proyecto, y protegerlo depende de una exclusión que vive en una sola máquina. Eso deja demasiado margen para el descuido humano, y hay 1,122 archivos públicos que lo demuestran. Mientras sale un arreglo de fondo, la mejor defensa es la vieja de siempre: los secretos viven en variables, no en los comandos.