Codex ships a remote-control command its own docs say does not exist
The subcommand pairs a headless Linux box to the ChatGPT mobile app, while OpenAI's Remote guide tells you the CLI cannot do that at all.
Tanishq Abraham's favourite Codex feature is one he found on Reddit.
He runs it every day. codex remote-control start on the GPU slurm cluster his lab logs into over SSH, then codex remote-control pair for a code, then that code goes into the Remote section of the ChatGPT mobile app on his phone. It appears nowhere in OpenAI's documentation.
So we went looking. The command is real, it is in the shipped binary, and the docs do rather worse than omit it.
Here is the relevant part of codex-rs/cli/src/main.rs and remote_control_cmd.rs in the openai/codex repository, verbatim:
/// [experimental] Manage the app-server daemon with remote control enabled.
RemoteControl(RemoteControlCommand),
enum RemoteControlSubcommand {
/// Start the app-server daemon with remote control enabled.
Start,
/// Stop the app-server daemon.
Stop,
/// Create and print a short-lived manual pairing code.
Pair,
}
Three subcommands. Start the daemon, stop the daemon, mint a short-lived pairing code. Not the shape of something left behind by accident.
The docs do not omit it. They deny it
OpenAI's Codex documentation index lists two Remote pages and neither mentions the CLI. And the "Remote connections" guide goes further, ruling it out in a sentence about what you need before you start.
The latest ChatGPT desktop app for macOS or Windows running on a host that's awake, online, and signed in to the same account and workspace. Mobile setup starts from the app; you can't set it up from the Codex CLI or IDE extension.
That is not an undocumented feature. It is a documented denial, and it is wrong.
Why would anyone write that sentence?
Why would a company deny its own command? Look at the shape of the supported path and the answer gets fairly clear. Remote assumes a host running the ChatGPT desktop app on macOS or Windows, paired by QR code, kept awake and online, signed in to the same account, with multi-factor or SSO steps on top and an admin toggle at the workspace level.
Every one of those assumptions breaks on the machine Abraham actually uses, which is a Linux login node he reaches over SSH and which will never run a desktop app.
The docs even propose a workaround for exactly his case. Connect the desktop app host to the remote environment first, and your phone still talks to that host. Which means keeping a Mac awake in the middle so a phone can reach a cluster.
So the subcommand is the escape hatch. Marking it experimental and leaving it out of the docs is roughly how you ship an escape hatch without owning it.
Anthropic has the same feature and writes it down
Claude Code's v2.1.252 notes carry a bug fix for "Remote Control sessions hosted by Claude Desktop or VS Code stalling for minutes after a tool finished when the connection to claude.ai was degraded". Two releases later a text form of /advisor arrived for "the desktop app, Remote Control, and other headless (-p/Agent SDK) sessions."
Dull sentences, both of them. That is the point. The feature is named in the changelog, so a user can search for it and an admin can reason about it.
This is a security gap before it is a documentation gap
remote-control pair mints a short-lived credential that gives a phone the ability to run commands on a host. Every piece of guidance about identity checks, device management and workspace enablement is attached to the flow this one is not on.
Run it on a shared cluster login node and think for a moment about who else has a shell there while the daemon is up.
As far as we can tell, nobody at OpenAI has written down what that pairing code is worth. Officially you cannot create one.
The fair defence is that experimental means what it says, and shipping an unfinished path behind a flag beats not shipping it at all. Fine. But the flag is not hidden (it sits in the top-level command list, where anyone running codex --help will see it), and a great many researchers have exactly Abraham's setup.
We would expect this documented or deleted before the end of 2026, probably the former. If a release note names remote-control and the Remote connections guide loses that sentence, the escape hatch has become a feature. If the subcommand quietly disappears instead, that tells you what OpenAI decided the pairing code was worth.
