Informe: Apiiro afirma que «Don't ask again» de Claude Code expuso contraseñas en 1122 archivos públicos de GitHub. Revisa .claude/settings.local.json

Veredicto: si alguien de tu equipo pulsó alguna vez «Yes, and don't ask again» en un comando que llevaba una contraseña, un token o una clave, asume que esa credencial está en .claude/settings.local.json, y comprueba si el archivo llegó a Git. La cifra de Apiiro es de segunda mano, porque no pudimos leer su artículo, pero el mecanismo está en la propia documentación de Anthropic: «Yes, and don't ask again» guarda la aprobación como una regla allow en .claude/settings.local.json, y Claude Code mantiene ese archivo fuera de los commits solo a través de tus exclusiones globales de git. Claude Code se mantiene en condicional en nuestro directorio: esto es un riesgo de configuración que puedes cerrar hoy, no una razón para abandonar la herramienta.

Qué ha pasado

La empresa de seguridad Apiiro publicó una investigación sobre el archivo de permisos que escribe Claude Code. Llegó a Hacker News el 7 de noviembre con el título «Claude Code's "Don't Ask Again" exposes passwords in 1,122 public GitHub files». El sitio de Apiiro rechazó nuestras peticiones (HTTP 403), así que no pudimos comprobar su método, sus otras cifras ni qué contaba como secreto. La documentación de ajustes de Anthropic confirma el mecanismo: cuando eliges «Yes, and don't ask again» para un comando Bash, Claude Code guarda esa aprobación como una regla allow en .claude/settings.local.json. Si el comando aprobado contenía una contraseña o un token, el secreto queda en esa regla.

Por qué el archivo acaba en Git

La primera vez que Claude Code escribe el archivo, añade **/.claude/settings.local.json a tu archivo global de exclusiones de git, no al .gitignore del repositorio. Un archivo global de exclusiones vive en una sola máquina, así que el propio repositorio no lleva ninguna regla que mantenga el archivo fuera, y la documentación dice que si creas el archivo a mano debes añadirlo tú mismo al .gitignore. No confíes en un escáner de secretos como último recurso: una contraseña dentro de una cadena de comando puede no coincidir con los formatos de claves que buscan los escáneres.

Qué ha dicho Anthropic

Boris Cherny, que lidera Claude Code, respondió en el hilo de Hacker News el 7 de noviembre: «Históricamente Claude Code no ha hecho limpieza de secretos (hay muchas buenas herramientas para eso), pero estamos estudiando qué podemos hacer para prevenirlo». En el mismo comentario escribió que el archivo «está pensado para quedarse en local», que Claude Code lo añade al gitignore automáticamente cuando lo crea, «así que en este caso los archivos se crearon manualmente y se incluyeron en commits». También aconsejó a los usuarios pasar al modo auto y activar el escaneo de secretos en su proveedor de Git. Ni la entrada del registro de cambios de 2.1.319 (6 de noviembre) ni la de 2.1.321 (9 de noviembre) abordan el tema. 2.1.321 sí corrige un bug de secretos distinto (las peticiones OAuth de MCP que enviaban tokens de refresco a otro host al ser redirigidas), que no es este problema. Trata el comportamiento como vigente.

Qué cambia para ti

Preguntas frecuentes

¿Mi secreto está expuesto si el archivo nunca salió de mi máquina? No a través de GitHub. La vía de exposición es que el archivo se incluya en un commit y se suba, así que comprueba el estado y el historial de Git antes que nada.

¿Un escáner de secretos lo detectaría? No de forma fiable. Una contraseña dentro de un comando aprobado puede no coincidir con los formatos que buscan los escáneres, así que busca directamente en el archivo.

¿Ha publicado Anthropic una corrección? No a fecha de la versión 2.1.321 del 9 de noviembre. Boris Cherny dijo que el equipo está «estudiando qué podemos hacer para prevenirlo».