Support Codex CLI as a Remote Control controller for another Codex host

What variant of Codex are you using?

CLI

What feature would you like to see?

Add a supported way for the Codex CLI/TUI on one computer to control a Codex Remote Control host on another computer through the existing OpenAI relay.

Today:

• codex remote-control start|stop|pair makes the CLI a Remote Control host.
• codex --remote connects the TUI to a directly reachable WebSocket or Unix socket.
• The CLI cannot enroll as a Remote Control controller, discover another registered host, and connect through the OpenAI relay.

The desired workflow is:

1. Enroll the local CLI as a controller using the current ChatGPT account.
2. List eligible online Codex hosts and select one.
3. Select a remote working directory or existing thread.
4. Launch the stock Codex TUI against that host.
5. Steer tasks, answer approval requests, inspect diffs, and resume after disconnection.
6. Revoke the controller identity when no longer needed.

Possible interface:

codex remote-control enroll
codex remote-control devices
codex remote-control connect [HOST_ID] [-C REMOTE_DIR]
codex remote-control revoke

The repository, tools, credentials, permissions, and authoritative thread state should remain on the remote host. The controller should not require SSH, inbound ports, repository synchronization, or a separate TUI.

An experimental proof of concept exists:

https://github.com/Typiqally/rcodex

It connects the stock Codex TUI to a paired Remote Control host through the relay. At Codex CLI 0.152.0 it has 38 passing tests covering controller enrollment, account/device binding, relay authentication, message segmentation, sequence validation, stale-stream rejection, credential safety, and the authenticated local TUI bridge.

The proof of concept also identified requirements for a production implementation:

• Reuse Codex's authentication manager instead of reading auth.json directly.
• Use non-exportable, cross-platform device signing keys.
• Bind enrollment and refresh operations to the account, client, challenge, and device identity.
• Share framing/protocol types with the existing Remote Control host implementation.
• Support cursor/ACK-based reconnection, retry backoff, and bounded buffering.
• Keep tokens out of command-line arguments.
• Decide and document the relay/E2EE trust model.
• Integrate the relay transport directly into app-server-client, avoiding a loopback shim and child process.

This differs from requests to control a CLI host from mobile or attach the local TUI to a chat on the same host: this request is specifically for the CLI to act as the controller of another registered Codex host.

Additional information

Related issues:

• #27565 — CLI host controlled from mobile; opposite direction
• #39793 — desktop/Linux app as a Remote controller
• #35504 — Windows desktop as a controller for a macOS host
• #32445 — attach the TUI to an existing chat on the same host
• #41970 — Remote Control relay/E2EE trust model

Official documentation currently says Remote setup requires the desktop app, while direct codex --remote App Server connections are experimental:

• https://learn.chatgpt.com/docs/remote-connections
• https://learn.chatgpt.com/docs/app-server

rcodex is unofficial experimental software and relies on observed, undocumented controller enrollment and relay behavior. The reference implementation is evidence that the CLI-controller workflow is viable, not a request to preserve those private interfaces unchanged.

Start by reading the existing remote-control host commands and the app-server-client entry point, then compare their authentication and relay behavior with the requirements in this issue. Review the existing Remote Control protocol and authentication manager before scoping the controller flow. Done means a supported CLI controller can enroll, discover and connect to a host, resume safely, and revoke its identity without exposing tokens.