El botón, el archivo y el comando
La firma de seguridad de aplicaciones Apiiro publicó el 6 de noviembre una investigación que encontró 2.539 secretos reales en 1.994 repositorios públicos de GitHub, casi todos escritos allí por el propio archivo de permisos de un agente de programación.
El mecanismo es de lo más común. Claude Code pregunta antes de ejecutar un comando de consola. Si se elige “Sí, y no vuelvas a preguntar”, guarda una regla de permiso en .claude/settings.local.json, dentro de la carpeta del proyecto. Cuando la regla aprobada es un comando literal y no un patrón, todo lo que se escribió en ese comando —una contraseña de base de datos, un token, un acceso SSH— queda guardado con él, en texto plano, en un archivo que convive con el código.
Apiiro rastreó GitHub público entre el 1 y el 3 de noviembre y encontró 104.185 copias de ese archivo en 103.617 repositorios. De ellas, 1.122, alrededor del 1,1%, contenían un secreto real: 1.379 valores distintos en total, de los que 636 coincidían con el formato de clave de un proveedor conocido y 743 eran contraseñas o tokens junto a un servidor público. Más de un tercio abre directamente una base de datos, incluidas 379 contraseñas de bases de datos y 122 claves de rol de servicio de Supabase, además de 43 accesos SSH a servidores públicos, 42 tokens de GitHub, GitLab y npm y 23 claves de AWS.
Por qué los archivos son públicos
Claude Code sí intenta que el archivo se quede en local: cuando lo crea dentro de un repositorio, lo añade a las exclusiones globales de git del desarrollador. Eso cubre el caso habitual y nada más. No cubre una carpeta que se convierte en repositorio después, ni un clon en una segunda máquina, ni un archivo que alguien ya ha subido, y la regla nunca entra en el .gitignore del propio repositorio, así que ninguna protección viaja con el proyecto.
Apiiro añade que a menudo es el propio agente quien sube el archivo: en 539 de los 1.105 repositorios con un secreto real que pudo rastrear, un commit coescrito por Claude modificó ese archivo. Las instrucciones de commit de Claude Code le dicen al modelo que no suba .env ni credentials.json; su propio archivo de configuración no está en esa lista. De 16 agentes de programación cuya documentación comparó Apiiro, dice que Claude Code es el único del que consta que escribe por defecto el comando aprobado completo en un archivo del proyecto.
La exposición no es breve. Todos los archivos afectados seguían en la rama principal de su repositorio cuando Apiiro los revisó, y en el caso mediano llevaban allí 217 días. Borrarlo no cierra el agujero: versiones anteriores del archivo guardan otros 734 secretos en 509 repositorios que no aparecen en ninguna copia actual, y 211 bifurcaciones de 74 repositorios arrastran los mismos valores.
Lo que los escáneres no ven, y lo que dice Anthropic
Los escáneres genéricos de secretos detectaron cerca de la mitad. Aplicados a los 104.185 archivos, gitleaks marcó 564 de los 1.122 con un secreto real y TruffleHog 643; 215 no los marcó ninguno. La diferencia está en las contraseñas escritas dentro de comandos —tras PGPASSWORD=, sshpass -p o mysql -p—, que parecen palabras corrientes y no formatos de clave.
Apiiro dice que avisó a cada organización afectada el 2 y el 3 de noviembre, y a Anthropic por el canal de divulgación que la empresa pide. También señala que los usuarios llevan informando del mecanismo en incidencias de GitHub de Claude Code desde agosto de 2025, que ninguna recibió respuesta y que tres se cerraron automáticamente por inactividad o duplicidad.
El responsable de Claude Code en Anthropic, Boris Cherny, respondió en Hacker News el 7 de noviembre. “Históricamente Claude Code no ha hecho limpieza de secretos (hay muchas buenas herramientas para eso), pero estamos viendo qué podemos hacer para evitarlo”, escribió, y citó “asegurarnos de que el modo automático lo detecte, incorporar un escaneo básico de secretos” entre los enfoques que el equipo prototiparía “antes de lanzar algo”. También dijo que Claude Code añade el archivo a gitignore cuando lo crea, así que, en su opinión, las copias expuestas se crearon a mano y se subieron.
Los límites del propio estudio se declaran con claridad: no se usó ni se probó ninguna credencial, y “secreto real” significa un valor que coincide con el formato de un proveedor o apunta a un servidor público, no uno que se sepa que funciona. Una empresa avisada confirmó que su clave estaba activa. El consejo que se desprende es poco vistoso: rotar todo lo que el archivo haya contenido alguna vez, dejar de rastrearlo y aprobar patrones en lugar de comandos literales.
