El botón "no preguntes de nuevo" de Claude Code filtró 2,539 contraseñas a GitHub

Un equipo de investigadores de Apiiro acaba de publicar un dato que debería incomodar a cualquier equipo que ya trabaja con agentes de código: entre el 1 y el 3 de noviembre de 2026 revisaron 104,185 copias públicas del archivo .claude/settings.local.json en GitHub y encontraron secretos reales —no ejemplos, no placeholders— en 1,122 de esos archivos. Contando commits históricos, archivos de configuración compartidos y transcripciones de agentes, la cifra total sube a 2,539 secretos distintos repartidos en 1,994 repositorios públicos, de 63 organizaciones, en su mayoría empresas de software. Al menos una ya confirmó que la llave expuesta estaba viva.

No hubo ningún hackeo de por medio. No hubo prompt malicioso ni cuenta robada. El problema está en una opción que probablemente tú mismo has usado esta semana: "Yes, and don't ask again" en Claude Code.

Qué pasó exactamente

Cuando usas Claude Code (o cualquier agente de código con permisos de ejecutar comandos en tu terminal) y aprietas esa opción para que deje de preguntarte cada vez que quiere correr un comando, Claude Code guarda el comando completo —tal cual, literal— como regla de "allowlist" en .claude/settings.local.json. El problema es que "completo" incluye cualquier contraseña, token o llave que hayas escrito directo en la terminal: una conexión con PGPASSWORD=, un sshpass -p, un mysql -p, una llamada a una API con el token pegado en el header.

Claude Code sí intenta protegerte: cuando crea ese archivo dentro de un repositorio de Git, lo agrega automáticamente al .gitignore global del desarrollador. El detalle que se le escapa a casi todo el mundo es que esa protección:

• No viaja con el proyecto cuando alguien más lo clona.
• No cubre archivos que ya estaban trackeados antes.
• No sirve si una carpeta que no era repositorio se convierte en uno después.

Apiiro encontró, además, que 734 secretos aparecían solo en versiones históricas —ya borrados del archivo actual, pero todavía vivos en el historial de Git— y que credenciales de 74 repositorios se replicaron hacia 211 forks adicionales. Borrar el archivo de hoy no borra nada del ayer.

Los números que sí importan

De los secretos encontrados, los más comunes fueron:

• 379 contraseñas de bases de datos.
• 122 llaves de servicio ("service-role") de Supabase y 103 tokens de cuenta de Supabase.
• 43 credenciales SSH, varias con contraseñas de root incluidas.
• 23 llaves de AWS y 6 llaves privadas.

Entre los ejemplos documentados hay una llave de administrador de un proveedor de bases de datos, una contraseña de producción de Azure PostgreSQL, un token de producción de Square y la contraseña del propietario de una base de datos de expedientes médicos. Esto no es un escenario hipotético de "podría pasar": ya pasó, está indexado en GitHub ahora mismo, y Google lo cachea.

Lo que más debería llamarte la atención, si trabajas con seguridad o con desarrollo, es el punto ciego de las herramientas que probablemente ya usas para esto: de los 1,122 archivos con secretos reales, Gitleaks detectó 564 y TruffleHog detectó 643. 215 archivos no fueron detectados por ninguno de los dos. La razón es simple: una contraseña después de PGPASSWORD= o sshpass -p no tiene el formato reconocible de una API key, así que los escáneres entrenados para detectar patrones de llaves (sk-, ghp_, etc.) la dejan pasar.

Por qué esto no es "un bug de Claude Code" y punto

Es tentador leer esto como una nota de "cuidado con la herramienta X". Pero el patrón real es más incómodo: cualquier agente de código al que le des permiso de ejecutar comandos de terminal y guardar aprobaciones automáticas va a tener este mismo problema de diseño, porque el riesgo no está en el modelo, está en dónde vive la sesión del humano que lo usa. Si tú pegas una contraseña en tu propia terminal normalmente, el agente que observa esa terminal la va a ver también. La diferencia es que ahora esa decisión de "no preguntes de nuevo" queda guardada en un archivo que, si no tienes cuidado, termina en un repositorio público.

Vale la pena decir que esto no es nuevo del todo: según cita Apiiro, ya había un issue público reportando almacenamiento de credenciales en texto plano en comandos aprobados desde agosto de 2025. El problema llevaba más de un año ahí, visible, y nadie le puso suficiente atención hasta que alguien contó los archivos.

Lo que esto significa para agencias, developers y tu producto

Si en tu equipo —o en el de tus clientes— ya están usando Claude Code, Cursor, o cualquier agente con modo "auto-aprobar", esto no es una nota para leer y pasar de largo. Son tres acciones concretas, en orden de prioridad:

1. Audita antes de limpiar. Busca .claude/settings.local.json en tus repos actuales y en el historial de Git (git log --all --full-history -- '**/.claude/settings.local.json'). Revisa también .claude/settings.json compartidos y cualquier transcripción de agente guardada en el repo.
2. Rota primero, borra después. Si encuentras una credencial real, rótala en el servicio de origen antes de tocar el archivo o reescribir historial. Borrar el archivo sin rotar la llave no protege nada —la copia pública ya existe en commits viejos, forks y cachés de buscadores.
3. No confíes solo en Gitleaks o TruffleHog para esto. Son buenas herramientas, pero 215 de 1,122 casos reales se les escaparon porque el patrón de una contraseña en un comando de shell no se parece al de una API key. Si tu pipeline de CI solo corre esos escáneres, agrega una revisión manual o una regla específica para patrones como PGPASSWORD=, sshpass -p, Authorization: Bearer pegado directo en comandos.

Para nosotros en Geek Vibes, el punto más grande no es técnico, es de proceso: cuando adoptas un agente de código en el flujo de un equipo —el tuyo o el de un cliente— la configuración de permisos no es un detalle de onboarding que se resuelve una vez. Es una superficie de seguridad que necesita su propia revisión, igual que revisarías los permisos de un nuevo empleado con acceso a producción. "Don't ask again" suena a comodidad de desarrollador; en la práctica, es una decisión de seguridad que casi nadie está tratando como tal.

Si estás evaluando cómo integrar agentes de código en tu equipo de forma segura —o quieres que auditemos la configuración actual antes de que termine como uno de estos 1,994 repositorios— escríbenos a hello@geekvibes.agency.