El agente de código de OpenAI que lleva tus claves SSH
La integración de Codex en ChatGPT Desktop — la aplicación de escritorio de OpenAI para macOS, Windows y Linux — hace algo que la documentación oficial nunca ha mencionado: reenvía tu agente SSH local a cualquier máquina remota donde el agente Codex ejecute comandos. El resultado es que, cada vez que ejecutas una tarea en Codex en un servidor remoto, ese proceso tiene acceso directo a tus claves SSH privadas, el mismo poder que tendrías si estuvieras conectado a esa máquina como tu usuario.
Cómo funciona
Al conectarse a un host remoto vía SSH, ChatGPT Desktop no añade explícitamente `-A` o `ForwardAgent=yes` a las opciones SSH — la aplicación sigue la configuración predeterminada de tu `~/.ssh/config` para ese host. El comportamiento inesperado aparece en el lado remoto: cada vez que la aplicación se conecta, ejecuta una línea de shell que verifica si hay un socket de agente SSH vivo (`SSH_AUTH_SOCK`) y lo vincula a `~/.codex/app-server-control/forwarded-ssh-agent.sock`. El servidor de la app Codex, iniciado en segundo plano por la aplicación, apunta su propio `SSH_AUTH_SOCK` a ese enlace simbólico. Cada comando que el agente ejecuta hereda ese socket.
El efecto práctico es directo: durante la sesión de conexión, `git push` a repositorios privados de GitHub, `ssh` a otros servidores y cualquier herramienta que use autenticación SSH en el servidor remoto se autentica como tú, no como el usuario remoto. El agente Codex puede hacer pushes a tus repositorios privados, crear branches y abrir pull requests — todo firmado con tus claves.
Qué muestra el código fuente
La prueba está en los propios repositorios de OpenAI. El pull request #28131 en el repositorio openai/codex, titulado "Refresh SSH agent for app-server proxy", contiene comentarios de revisión de ingenieros discutiendo la línea de entorno del daemon `SSH_AUTH_SOCK=~/.codex/app-server-control/forwarded-ssh-agent.sock`. La bandera `--forward-ssh-agent` en la integración del app-server de Codex hace exactamente lo que el nombre indica: lleva el agente SSH local del usuario y lo disponibiliza dentro del entorno de ejecución del agente. Revisiones en el mismo pull request discuten casos borde de symlinks stale tras nuevas sesiones SSH — lo que confirma que este comportamiento es intencional, no un bug.
Un issue abierto (#59694) documenta un problema derivado: cuando clientes Windows y macOS del Codex desktop se conectan a la misma cuenta NixOS, un cliente conectado puede reemplazar el socket SSH reenviado del otro. Esto muestra que el mecanismo no es solo real, sino que también presenta efectos colaterales observables en escenarios multiplataforma.
Qué dice la documentación (y lo que no dice)
La documentación de "Remote connections" del ChatGPT Learn detalla cómo configurar hosts SSH en Codex: añadir aliases al `~/.ssh/config`, confirmar conectividad e instalar el comando `codex` en el PATH remoto. Recomienda mantener hosts remotos con las mismas expectativas de seguridad del acceso SSH normal — claves confiables, cuentas de mínimo privilegio y sin listeners públicos desautenticados. Pero no menciona el reenvío del agente SSH en ninguna sección. El documento de seguridad del Cloud Security tampoco aborda este aspecto.
En la página de lanzamiento oficial de OpenAI, "Work with Codex from anywhere", el artículo describe el relay seguro, la sincronización de estado entre dispositivos y el soporte HIPAA para workspaces Enterprise. El reenvío del agente aparece silenciosamente como un detalle de implementación, no como una decisión de seguridad que merezca destaque en la documentación principal.
Por qué importa
La regla clásica de la seguridad SSH es simple y antigua: nunca reenvíes tu agente SSH a un host que no confías completamente. Un atacante en el servidor remoto podría usar tu agente para firmar commits de Git como tú, acceder a repositorios privados o hacerse pasar por ti en otras conexiones SSH. El reenvío existe para permitir acceso administrativo a servidores — te conectas al servidor A y, desde allí, accedes al servidor B usando tus credenciales locales. La conveniencia es innegable, pero el riesgo es ampliamente conocido.
Lo que ChatGPT Desktop hace es diferente en un punto crucial: el riesgo no viene de un atacante en el servidor, viene del propio agente de OpenAI ejecutando código arbitrario en ese servidor. Si el Codex ejecuta un comando que activa `git push`, tus claves firman el commit. Si el agente corre un script que se conecta a otro servidor, tu agente autentica la conexión. El usuario no ve ninguna confirmación de que sus claves están siendo usadas — la interacción es totalmente invisible dentro del entorno del agente.
Especialistas en seguridad ya han alertado sobre riesgos similares. Un artículo de Privacy Affairs detalla cómo se descubrió el comportamiento y se mapeó paso a paso. El artículo en DEV Community señala el PR #28131 de OpenAI como prueba irrefutable: tres artefactos públicos — la bandera `--forward-ssh-agent`, el socket estable en `~/.codex/app-server-control/forwarded-ssh-agent.sock` y issues documentando efectos colaterales en múltiples clientes — forman um caso de auditoría aberto. Palo Alto Networks, en directrices para equipos empresariales de Codex, recomienda explícitamente restringir qué agentes pueden ejecutar y aislar entornos de ejecución de herramientas de IA.
Qué puedes hacer ahora
La buena noticia es que el reenvío no se activa automáticamente — solo ocurre cuando tu `~/.ssh/config` pide `ForwardAgent yes` para ese host específico o para `Host *`. Si nunca activaste el reenvío en ninguno de tus hosts, el agente no tiene nada que reenviar. Pero si usas forwarded agent para administración de servidores, ChatGPT Desktop acaba de convertirse en otro host de confiança en tu cadena.
Para protegerte sin abandonar Codex:
1. Verifica si hay un socket reenviado. Ejecuta `ls -la ~/.codex/app-server-control/forwarded-ssh-agent.sock` en el servidor remoto. Si el enlace existe, tu agente está siendo reenviado.
2. Crea un alias dedicado para ChatGPT Desktop. Añade al inicio de tu `~/.ssh/config`, antes de cualquier bloque `Host *`, un bloque como `Host devbox-chatgpt` seguido de `ForwardAgent no`. Esto impide que la aplicación herede el reenvío de otros hosts.
3. Considera claves dentro de un secure enclave. Claves almacenadas em enclaves seguros en macOS o Windows requieren confirmación biométrica para cada uso — huella digital ou PIN. Aunque el socket sea reenviado, el agente no puede firmar sem tua interação física.
4. Monitorea tus repositorios. Verifica os logs de commit de GitHub nos últimos días para confirmar si algún push fue hecho mientras Codex estaba conectado.
Lo que ChatGPT Desktop hace con tu agente SSH no es un bug — es una funcionalidad non documentada que transforma un servidor remoto en un puente directo a tus identidades digitales. El principio de "confianza cero" del SSH data de décadas, pero agentes de código autónomos como Codex están redesignando lo que "máquina confiable" significa en 2026. La pregunta que queda: cuando herramientas de productividad comienzan a llevar tus claves criptográficas a entornos remotos, quién debe aprobar ese riesgo — el usuario final o el fabricante del software?
Fuentes: Privacy Affairs, DEV Community, Hacker News
✓ Fuentes independientes cruzadas y verificadas antes de la publicación
