Una decisión pensada para ahorrar interrupciones puede dejar una contraseña en un lugar inesperado. Cuando un agente pide permiso para ejecutar un comando y el usuario acepta recordarlo, la herramienta necesita guardar qué ha autorizado. Si la orden incluye una credencial escrita directamente, también puede quedar dentro de esa configuración.
La investigación publicada por Apiiro el 5 de noviembre, y actualizada el día 8 con la respuesta de Anthropic, describe ese recorrido en Claude Code. La firma identifica 2.539 secretos en 1.994 repositorios públicos de GitHub. Su clasificación no demuestra que todos sigan funcionando: los investigadores dicen que no utilizaron las credenciales ni contactaron con los servidores.
El problema empieza antes de subir el código
Según el análisis, una autorización persistente puede almacenar la orden completa en .claude/settings.local.json. Si contiene una contraseña o un token, ese valor queda junto al permiso. El segundo paso es que el archivo termine incluido en una publicación del proyecto.
Dentro de la muestra, 1.122 archivos locales de configuración contenían secretos, entre 104.185 copias públicas examinadas. El resto del recuento abarca otros lugares, incluido historial y registros. Esas cifras describen la muestra analizada, no el porcentaje de todos los usuarios de Claude Code afectados.
La documentación de permisos de Claude Code ayuda a entender el mecanismo. Las reglas permiten recordar qué comandos, herramientas o dominios se han autorizado, en lugar de volver a preguntar en cada ocasión. Existen configuraciones compartidas del proyecto y ajustes locales. Que ambos estén cerca del código no significa que tengan la misma finalidad.
Una regla útil para un compañero puede describir una operación repetible. Una contraseña da acceso a un servicio. Mezclar las dos cosas convierte una comodidad del flujo de trabajo en una nueva copia de información sensible.
Por qué añadir un archivo a gitignore puede llegar tarde
La guía oficial de Git distingue entre archivos que todavía no están bajo seguimiento y aquellos que ya forman parte del repositorio. Las reglas de exclusión sirven para los primeros; no dejan de publicar automáticamente los segundos.
Esa diferencia explica por qué no basta con comprobar que existe una línea de exclusión en algún lugar. Una configuración global pertenece al entorno de una persona. El archivo .gitignore del proyecto viaja con el código cuando se comparte. Y, si un archivo ya está registrado, hay que revisar expresamente su seguimiento y lo que conserva el historial.
Para un equipo, la comprobación práctica es mirar qué entra realmente en cada cambio antes de publicarlo. El nombre «local» describe una intención del programa, pero no constituye por sí mismo una barrera que impida que Git guarde el archivo.
La respuesta del responsable de Claude Code
Boris Cherny, responsable de Claude Code, respondió el 7 de noviembre en Hacker News. Explicó que el archivo está pensado para quedarse en el equipo y que Claude lo excluye de Git cuando lo crea. También defendió el modo automático y recomendó utilizar detección de secretos.
En respuestas posteriores habló de estudiar medidas como detección básica de credenciales y mejoras del modo automático. Son propuestas en evaluación: no un parche general cuya distribución y eficacia estén acreditadas por esa conversación.
La discrepancia importa. El equipo señala el comportamiento previsto de creación del archivo; el informe describe casos donde esa protección no basta para evitar la publicación. Para quien mantiene un proyecto, la pregunta inmediata es qué se ha guardado y compartido realmente.
Si una clave salió del equipo, borrarla no la invalida
La documentación de GitHub sobre datos sensibles recomienda empezar por revocar o rotar una credencial expuesta. Eliminar una línea visible no cambia la contraseña que un servidor sigue aceptando ni garantiza que desaparezcan las copias anteriores.
La limpieza del historial es una operación diferente y puede afectar a colaboradores, firmas y referencias. Por eso conviene tratar por separado el acceso comprometido, el archivo publicado y la prevención de futuras copias.
La lección para quienes programan con agentes es concreta: revisar los permisos persistentes como parte del proyecto, mantener las credenciales fuera de las órdenes literales y comprobar el contenido de los cambios. Un asistente puede ahorrar trabajo, pero sus archivos auxiliares también pueden terminar formando parte de lo que se publica.