El botón que evita que el agente pregunte una y otra vez guarda la orden aprobada, credenciales incluidas, dentro de un archivo de configuración. Apiiro revisó miles de copias públicas de ese archivo en GitHub y encontró secretos en más de un millar.
El hallazgo de Apiiro sobre Claude Code: credenciales en texto plano
Apiiro publicó la investigación el 5 de noviembre. No habla de un fallo del modelo ni de un servidor comprometido: habla de qué ocurre cuando alguien acepta una orden para siempre.
El botón se llama, en la interfaz, "Yes, and don't ask again". Al pulsarlo, Claude Code deja de preguntar por ese comando concreto, y para eso lo guarda por escrito.
El destino es .claude/settings.local.json. Ahí queda una regla de allowlist con el comando tal como se escribió, incluidos sus argumentos. Si dentro del comando había una contraseña, la contraseña también está en el archivo.
Los ejemplos del informe son órdenes corrientes: PGPASSWORD=... psql, sshpass -p ..., mysql -p.... Cosas que un desarrollador lanza a mano cada día y que, aprobadas una vez, se copian al archivo sin que nadie vuelva a mirarlas.
Cómo funciona el botón "Don't ask again" de Claude Code
La idea de producto tiene sentido. Un agente que pregunta cada dos minutos por el mismo comando es un agente que nadie deja suelto.
El problema es qué se guarda y dónde: la regla no dice "permite ejecutar psql", dice "permite ejecutar este comando exacto", con su contraseña dentro.
Y ese archivo vive en el repositorio, en una carpeta llamada .claude. Cuando el proyecto sube a GitHub, la carpeta sube con él salvo que alguien la excluya antes.
Aquí conviene precisar una cosa, porque es la que más se malinterpreta. Claude Code sí añade ese archivo a la lista global de ignorados de Git cuando lo crea dentro de un repositorio. La protección existe. Lo que no hace es viajar: ni con el proyecto, ni con las copias, ni con los forks.
Qué apareció en los settings.local.json públicos de GitHub
Apiiro revisó 104.185 copias públicas del archivo repartidas en 103.617 repositorios. De todas ellas, 1.122 contenían secretos: 1.379 en total, contados uno a uno.
El desglose ayuda a ver el tipo de daño. 636 eran claves con formato de proveedor. Las otras 743 eran contraseñas o tokens de servicios con host público, entre ellas 379 contraseñas de bases de datos, 122 claves service-role de Supabase, 103 tokens de cuenta de esa misma plataforma, 23 claves de AWS y seis claves privadas.
Las 43 credenciales SSH merecen un párrafo aparte. Varias aparecían dentro de comandos sshpass, y algunas eran inicios de sesión como root.
El alcance del Claude Code secrets leak: 63 organizaciones
La muestra anterior es la estrecha. Apiiro amplió el barrido a archivos de configuración compartidos, transcripciones de agentes e historial de Git, y ahí aparecieron 2.539 secretos distintos en 1.994 repositorios públicos, con 63 organizaciones afectadas.
Dos detalles más del informe apuntan al mismo sitio. Las versiones antiguas de esos archivos guardaban 734 secretos que ya no están en las copias actuales, y los forks reprodujeron credenciales de 74 repositorios en 211 copias adicionales.
Ese último punto rompe la intuición de "lo borro y ya". Un fork no hereda la corrección: hereda el contenido.
Ahí está el problema.
Por qué la lista de ignorados no protege las Claude Code credentials
La explicación cabe en una frase: la lista global de ignorados es una preferencia de la máquina, no una propiedad del proyecto.
Quien creó el archivo en su portátil tiene la regla. Quien clona el repositorio después no la tiene, y el archivo ya está ahí. Lo mismo vale para el historial: aunque hoy el archivo esté fuera del árbol de trabajo, el commit antiguo sigue accesible para cualquiera con permiso de lectura.
Los escáneres que no detectan las contraseñas de Claude Code
Dos herramientas conocidas pasaron por encima de la muestra. Gitleaks marcó 564 de los archivos con secretos. TruffleHog marcó 643.
Ninguna de las dos vio 215 archivos. ¿Por qué nadie lo vio antes? La razón no es un error de programación: las contraseñas escritas como PGPASSWORD=, sshpass -p o mysql -p no llevan prefijo de proveedor, y sin prefijo no hay patrón que buscar.
Traducido a la práctica diaria, el escáner del CI cubre las claves de AWS y se pierde la contraseña de la base de datos que va en la misma línea de comandos. El agujero no está en la herramienta. Está en la forma de escribir el comando.
Qué hacer esta semana con las credenciales de Claude Code
El orden importa, y Apiiro lo deja claro: primero rotar, después borrar.
Rotar antes de tocar el archivo evita el escenario absurdo de limpiar el repositorio mientras la credencial sigue viva en otro sitio. Después toca destrackear el archivo sin borrarlo del disco, añadir reglas de ignorado locales al repositorio y no solo a la máquina, y revisar el historial, los archivos compartidos y las transcripciones del agente.
El último paso es el que cuesta: sustituir los literales por variables de entorno apoyadas en un gestor de secretos. Cuesta porque obliga a cambiar la forma de lanzar los comandos, que es justo el motivo por el que el atajo del botón resulta tan tentador.
En España, el patrón aparece en cuanto una consultora subcontrata: el repositorio pasa por cuatro manos y la carpeta .claude viaja con él. Si la credencial abría una base con datos personales, toca mirar los plazos de notificación del RGPD y lo que pide la AEPD.
La lección del Claude Code secrets leak para cualquier agente
Hay un límite que conviene decir en voz alta. Apiiro no probó las credenciales ni contactó a los servicios afectados, así que "secreto" significa material creíble, no un inicio de sesión verificado. Una sola organización confirmó que una clave expuesta había estado activa.
Tampoco hay declaración de Anthropic en el informe, ni CVE, ni versión parcheada que instalar. Y el patrón no es exclusivo de esta herramienta: cualquier agente que ofrezca la opción de no volver a preguntar está tomando una decisión de almacenamiento de credenciales, aunque la presente como una preferencia de interfaz.
Esa es la frase que debería quedarse en la cabeza de quien diseñe el próximo botón. Preguntar cansa. Guardar, a veces, cuesta más.
