ChatGPT Desktop reenvía tu agente SSH a servidores remotos — y Codex puede hacer push como tú

Un post en Hacker News esta semana planteó una pregunta silenciosa pero potencialmente seria sobre la arquitectura de seguridad del ChatGPT Desktop: cuando conectas la aplicación a un servidor remoto vía SSH, el agente de codificación heredado en ese servidor tiene acceso a tu agente SSH local — lo que significa que puede autenticarse en tu nombre en repositorios privados de GitHub y en cualquier servidor que confíe en tus claves.

Qué se descubrió

La discusión ganó tracción el lunes 9 de noviembre, cuando el usuario DenGaborchev publicó una afirmación directa en Hacker News: «El agente ejecutándose en una máquina remota puede autenticarse usando tus credenciales SSH locales. Esto significa que puede hacer push a tus repos privados en GitHub, por ejemplo». El enlace de «prueba» era un comentario en una revisión de código en el repositorio openai/codex (pull request #28131), hecho por el ingeniero de OpenAI abhinav-oai, describiendo el flag `--forward-ssh-agent` y cómo el socket del agente se enlazaba a una ruta estable en disco (`~/.codex/app-server-control/forwarded-ssh-agent.sock`).

Lo que hace la cuestión más interesante es que el pull request en cuestión fue cerrado sin ser merged — lo que llevó a comentaristas en HN a cuestionar la «prueba». Sin embargo, PrivacyAffairs verificó en la versión más reciente del build de macOS (26.1103.60933, construida el 8 de noviembre) que el comportamiento existe de hecho: la aplicación no activa el reenvío por sí misma, pero cuando la configuración SSH del usuario (`~/.ssh/config`) ya tiene `ForwardAgent yes`, la aplicación asegura que el servidor de agente en segundo plano mantenga las claves accesibles para el Codex que corre en el servidor remoto.

Cómo funciona técnicamente

El ChatGPT Desktop, desde julio de 2026, integra el Codex — el agente de codificación de OpenAI — como parte de su funcionalidad de desarrollo remoto. En los ajustes de la aplicación, el usuario añade un host remoto desde `~/.ssh/config`, y los chats en ese proyecto leen archivos y ejecutan comandos en el servidor. La aplicación se conecta usando OpenSSH, según la documentación.

El detalle crítico, sin embargo, no aparece en la documentación de OpenAI. Cada vez que la aplicación se conecta, ejecuta una línea de shell en el servidor: si la sesión tiene un socket de agente SSH activo (`SSH_AUTH_SOCK`), lo enlaza a `~/.codex/app-server-control/forwarded-ssh-agent.sock`. El servidor de la app Codex, iniciado en segundo plano con `nohup`, tiene su `SSH_AUTH_SOCK` apuntando a este enlace. Cada comando que el agente ejecuta hereda esta variable de entorno.

Mientras la aplicación está conectada, `git` y `ssh` en el servidor pueden autenticarse con cualquier clave cargada en el agente de tu ordenador. Esta es una capacidad intencional, no un bug — los usuarios informaron en un bug report (issue #22567) que el Remote SSH ignoraba `ForwardAgent` y rompía `docker buildx build --ssh`. En junio de 2026, el ingeniero Abhinav Vedmala propuso un flag `--forward-ssh-agent` en el pull request #28131. El comportamiento actual, aunque el flag ya no está en el branch principal del Codex, implementa la misma funcionalidad a través de un script de shell propio de la aplicación.

Por qué importa más con un agente de IA

La diferencia entre un agente de IA y un script manual es que el agente lee instrucciones de texto — READMEs, issues de GitHub, comentarios en pull requests. Y la propia documentación de seguridad de OpenAI advierte que «la inyección de prompt puede hacer que el agente busque y siga instrucciones no confiables». Un agente de codificación que lee un README envenenado o un issue tiene tu identidad a mano para GitHub y para cada servidor que confía en tu clave.

Existe un freno: por defecto, Codex se ejecuta con acceso de red apagado y pregunta antes de comandos que lo necesiten. Un `git push` espera tu aprobación. Ese prompt es la única protección, y te protege solo en la medida en que lo lees con atención.

Los escenarios más expuestos son exactamente aquellos que la propia documentación de GitHub advierte contra: `ForwardAgent yes` bajo `Host *`, que significa «estariás compartiendo tus claves SSH locales con cada servidor al que hagas SSH». Con la app de ChatGPT, también las estarías compartiendo con la IA que trabaja en esos servidores.

Cómo verificar y desactivar

PrivacyAffairs recomienda dos verificaciones inmediatas. Primero, verificar si existe un socket de agente reenviado para tu herramienta de IA:

``` ls -la ~/.codex/app-server-control/ 2>/dev/null || echo "no codex agent socket" ```

Segundo, qué claves podrían ser firmadas en este momento:

``` ssh-add -l ```

Si la salida es «The agent has no identities.», nada que abusar. Si hay una lista de fingerprints de clave, estos pueden ser firmados, silenciosamente, por cualquier proceso que comparta tu agente.

Para desactivar el reenvío solo para la app de ChatGPT, crea un alias específico con reenvío desactivado, por encima de cualquier bloque `Host *`:

``` Host devbox-chatgpt HostName devbox.example.com ForwardAgent no ```

Luego, añade ese alias en Settings > Connections de la aplicación.

El patrón más amplio

Esta no es la primera vez que un agente de codificación plantea preocupaciones sobre la gestión de credenciales. La semana pasada, Apiiro reportó que Claude Code, con el default «Don't Ask Again» activado, vazó claves en más de 1.100 repositorios. El problema subyacente es el mismo: herramientas de agente de IA estandarizando hacia reutilización máxima de credenciales, cuando la seguridad por defecto debería ser lo mínimo necesario.

La frontera entre lo que el agente lee y lo que el agente puede hacer continúa desplazándose. Históricamente, los agentes de IA podían leer tus archivos y ejecutar comandos autorizados. Ahora, con el reenvío del agente SSH, pueden actuar en tu nombre — no solo ejecutando comandos, sino firmando commits, haciendo push a repositorios privados y autenticándose en servidores como si fueras tú. La pregunta es si el modelo de confianza implícito entre el usuario y el agente de IA es suficiente, o si necesitamos una capa adicional de verificación explícita para cada operación sensible que un agente realiza con nuestras credenciales.

Fuentes: PrivacyAffairs, DEV Community, AI Weekly

✓ Fuentes independientes cruzadas y verificadas antes de la publicación