La idea es la misma que con Claude Code: un agente que vive en el servidor, arranca solo y al que te conectas desde donde estés. Con Codex hay dos formas de hacerlo, y las usamos las dos.

	Remote Control	Proyecto remoto por SSH
desde	app de ChatGPT en el móvil	ChatGPT Desktop (Mac o Windows)
qué haces	continuar tareas, aprobar acciones, ver diffs	trabajar en una carpeta del servidor como si fuera local
requisito	servicio `codex-remote-control` activo	alias SSH en tu equipo

Paso 1 · Instalar Codex como usuario, no como root

Usa la release oficial standalone en el perfil de tu usuario. El binario activo queda en ~/.codex/packages/standalone/current/bin/codex con un enlace en ~/.local/bin/codex.

codex --version
codex login status        # «Logged in using ChatGPT»

La autenticación vive en el servidor y no se copia a ningún otro equipo. No muevas ~/.codex/auth.json de máquina en máquina: si lo necesitas en otro sitio, inicia sesión allí.

Paso 2 · El servicio de Remote Control

Linger activado (como en la guía anterior) y una unidad de usuario que lanza el App Server con Remote Control:

sudo loginctl enable-linger $USER
systemctl --user enable --now codex-remote-control.service
codex app-server daemon version

Lo importante de cómo queda:

el App Server escucha en un socket Unix privado, no en un puerto TCP;
no se abre nada nuevo hacia fuera: la conexión con ChatGPT la inicia el servidor;
tras un reinicio vuelve solo.

En la app de ChatGPT del móvil, abre Remote y busca el nombre de tu servidor. Tiene que ser la misma cuenta y el mismo espacio de trabajo con el que se autenticó.

Paso 3 · El alias SSH para ChatGPT Desktop

En el equipo donde usas ChatGPT Desktop, ~/.ssh/config:

Host mi-servidor
    HostName 100.x.y.z          # la IP de Tailscale del servidor
    User tu_usuario
    StrictHostKeyChecking yes

Compruébalo desde una terminal de ese mismo equipo antes de tocar la app:

ssh mi-servidor 'bash -lc "codex --version"'

Después, en ChatGPT Desktop: Settings → Connections → SSH host, eliges mi-servidor y una carpeta de proyecto (por ejemplo ~/apps/mi-app). La app arranca el App Server remoto por SSH. No lances otro Codex a mano sobre el mismo proyecto mientras tanto.

El bash -lc no es decoración: sin shell de login, el PATH no incluye ~/.local/bin y la app dice que Codex no está instalado aunque lo esté.

Cuando deja de funcionar

A nosotros nos pasó: el servicio llevaba días en failed con «remote control connection is errored». No faltaba nada; el daemon anterior se había quedado en un estado de error. Lo que lo arregló:

systemctl --user daemon-reload
systemctl --user restart codex-remote-control.service
journalctl --user -u codex-remote-control.service -n 80 --no-pager

Reglas para reparar sin romper otra cosa:

no borres ~/.codex;
no copies auth.json;
no detengas Nginx, Docker ni ningún otro servicio «por si acaso» para arreglar Codex.

Si generas un código de emparejamiento con codex remote-control pair para probar, no lo guardes ni lo pegues en ningún sitio: es una credencial temporal.

Una trampa del catálogo de modelos

Si usas Codex con un proveedor de modelos propio (nosotros lo probamos contra el gateway del laboratorio), cambiar el catálogo en disco no actualiza una app de Codex ya abierta . Cierra y abre. Y en general: un proceso de larga vida lleva su configuración en memoria, cambiar el fichero no basta (P-080).

Deshacerlo

systemctl --user disable --now codex-remote-control.service

Solo retira el host remoto; no toca proyectos, modelos, Nginx ni nada de producción.

Siguiente: Pi en el móvil, un agente de terminal con interfaz web propia y varias sesiones a la vez.