Codex CLI Remote Control: Setup, Security & Access

Codex CLI remote control needs a clear boundary

The idea of Codex CLI remote control is simple. You control a coding agent on one computer from another device. In practice, it has two related parts. Codex has an experimental CLI command named codex remote-control. The ChatGPT desktop and mobile apps give a separate remote function for phones and other computers. The two parts overlap, but one cannot replace the other.

The difference is important when a phone cannot connect, when a workspace blocks mobile access, or when an operating system asks for device discovery. It is most important when the host (the computer where Codex does the work) has client files, credentials or access to production.

This guide tells you what each part does and how authentication and workspace policy change access. It also shows where the real security boundary is. Last, it gives a few workflows in which a person stays in control of important actions.

What Codex CLI remote control and Codex Remote Control actually mean

The term “Codex CLI remote control” can mean two capabilities. The first is the experimental codex remote-control command. It manages remote control for a local Codex app server (the local Codex process that other apps connect to). It can also create a short-lived pairing code (a code that links two devices). The second capability is in the ChatGPT mobile app. There, the Codex entry on iOS (Remote in older builds) lets a phone work with chats on a connected Mac or Windows host.

OpenAI’s CLI command reference says that managed remote-control clients and SSH remote workflows use the CLI commands. The Remote connections guide says that mobile setup starts in the ChatGPT desktop app. You cannot set it up from the Codex CLI or from the IDE extension.

Capability	Where setup starts	Main purpose	Status
codex remote-control	Terminal	Run remote control for the local app server or create a pairing code	Experimental
Codex on mobile (formerly Remote)	ChatGPT desktop app on the host	Start, continue, review and approve host-based work from a phone	Availability changes with the rollout
--remote CLI option	Terminal	Connect a CLI session to an app-server endpoint over WebSocket or a Unix socket	Documented CLI option
SSH host connection	Desktop app and ~/.ssh/config	Work against a remote filesystem and shell	Supported workflow

Think of the phone or the second computer as the steering wheel and the connected host as the engine. The files, credentials, tools, sandbox settings and approvals of the host still control the work. Sandbox settings are limits on what commands can read, write or reach.

How to start Codex CLI remote control

The official CLI procedure is short. Do not build a homemade tunnel for remote access. A homemade tunnel can quickly become a security problem. Use these commands:

1. Run codex remote-control to start remote control. If your setup is eligible, the command uses the managed background server. If your setup is not eligible, the command runs in the foreground.
2. If you want the command to run in the foreground on purpose, run codex remote-control --no-daemon. For example, do this to watch the output during a test.
3. Run codex remote-control start to start the local app-server daemon (a background program) with remote control enabled.
4. After the daemon starts, run codex remote-control pair. The command creates and prints a short-lived manual pairing code. If another program needs structured output, add --json.
5. Run codex remote-control stop to stop the daemon. The daemon then stops accepting remote-control connections.

For pair, the JSON response contains four documented fields:

• pairingCode
• manualPairingCode
• environmentId
• expiresAt

The command reference also says that these commands do not replace codex app-server --listen when you build a local protocol client. Use the remote-control command for managed pairing. Use the app-server interface only if you develop a client and know its transport and authentication requirements.

What to do when Codex Mobile is disabled by your workspace admin

If you see “Codex Mobile is disabled by your workspace admin,” the cause is a policy, not a pairing bug. A reinstall, a new QR code or a different Wi-Fi network will not remove a restriction that an administrator set.

OpenAI’s managed configuration guide documents a top-level allow_remote_control field in requirements.toml. Admins of cloud-managed users set it with Edit as TOML in Agent security. With allow_remote_control = false, device remote control is disabled. If the file does not contain the key, the requirements do not limit remote control. The normal product availability checks then apply. The same page says that this requirement does not disable SSH remote connections.

Symptom	Most likely layer	What to do
“Codex Mobile is disabled by your workspace admin”	Workspace or managed-device policy	Ask the workspace owner or admin to review Remote Control access
Codex (or Remote) is missing in the phone app	App version, account eligibility or rollout	Update ChatGPT. Make sure that you have Codex access in that workspace
Host does not appear	Pairing, account, workspace or host availability	Make sure that both devices use the same account and workspace
Approval request never reaches the phone	Old pairing or wrong workspace	Scan the QR code again or restart setup from the host. Then make sure that the admin allows access
Remote Control is off after sign-in	Expected sign-out behavior	After you sign back in, turn Remote Control on again

When the admin reviews the restriction, keep the other Codex security controls in place. Remote Control availability, sandbox permissions, command approvals, filesystem limits and network policy are separate layers. A team can allow mobile supervision and still require approval for risky commands. The team can also still block sensitive directories. The workspace admin guide gives more detail about the conversation with the admin.

OpenAI also gives a migration date, June 8, 2026. A connection that nobody used on or after June 8, 2026 needs updated apps on both devices and a new pairing. Connections that people used on or after that date stay paired.

Understanding “allow this device to be discovered and controlled by Codex” prompts

The text “Allow this device to be discovered and controlled by Codex” can mix up three prompts with different powers. They are an operating-system permission for discovery, a ChatGPT setting for the host connection and a Codex approval for an action.

An OS prompt for network discovery can let an app find or talk to local devices. The ChatGPT desktop app has the setting Settings > Connections > Control this Mac or PC. The troubleshooting text calls it Allow other devices to connect. This setting makes the host available through the supported remote connection. A Codex approval prompt authorizes one command or action. If you accept one of these prompts, you do not also accept the other two.

Boundary	What it permits	What it does not automatically permit
Device discovery	Local device visibility or communication allowed by the OS	Reading every file or running arbitrary commands
Remote host connection	An authorized device can work with host-backed chats	Bypassing the host sandbox or approval policy
Command approval	One action, or a defined class of actions, can go ahead	Permanent unrestricted remote access
Filesystem policy	Read or write access to specified locations	Network access to arbitrary domains
Network policy	Connections allowed by the active rules	Access to credentials outside the permitted environment

When the prompt “allow this device to be discovered and controlled by Codex” appears, read the full dialog. Find out which application showed it. Do not approve it only because it mentions Codex. Make sure that you pair the intended phone or computer with the intended host.

The Remote connections guide says that a secure relay (a server that passes traffic between devices) keeps trusted machines reachable from your authorized ChatGPT devices. The relay does not expose the machines directly to the public internet. The guide also says that the sandboxing settings, security controls and action approvals of the host still apply. Remote control keeps the existing security controls in place. It does not remove them.

Authentication, networks, and the real security boundary

Codex remote control uses the environment and the security boundaries of the connected host. Repository files and local documents come from that host. Shell commands run on the host or in its configured SSH environment. MCP servers, skills, browser access, Computer Use, signed-in websites and local tools come from the configuration of the host.

For mobile access, the phone and the host must use the same ChatGPT account and workspace. The setup can ask for MFA, SSO or a passkey. The QR code pairs one phone with one host. Pair each phone or desktop device with each host that you want it to control. A host runs the ChatGPT desktop app on macOS or Windows. The controlling device can be ChatGPT on iOS or Android. It can also be another Mac or Windows computer where Control other devices is available.

For SSH workflows, OpenAI’s guide follows normal secure-shell practice:

• Add the host to ~/.ssh/config. Codex reads concrete host aliases from that file and ignores pattern-only hosts (host entries that use wildcards).
• Use trusted keys and least-privilege accounts (accounts with only the access that the work needs). Do not open public listeners without authentication.
• Before you use Codex, make sure that ssh host-alias works from the machine that runs the app.
• Install Codex on the remote host. Sign in to Codex there. Keep the codex command on the PATH of the remote login shell.
• Do not expose app-server transports directly on a shared or public network.
• If you need to reach a remote machine outside your network, use a VPN or a mesh networking tool.

The CLI option --remote-auth-token-env reads a bearer token from an environment variable. The documented transport rule is important. The CLI sends tokens only over wss:// URLs or local-only ws:// URLs. This rule protects the token in transit. It is not a reason to publish an app-server endpoint on the internet.

One Codex CLI security boundary is firm. Never run a remotely reachable host with broad credentials and approval bypasses for convenience. The --dangerously-bypass-approvals-and-sandbox flag (alias --yolo) runs every command without approvals or sandboxing. OpenAI’s reference says that you must use it only inside an externally hardened environment. The guide to running Codex without approvals shows safer setups.

Four practical Codex CLI remote control workflows

In the best remote-control workflows, a person reviews important actions from a phone. The phone does not become a tiny development workstation.

1. A consultant reviews a proposal build away from the desk. The host makes a PDF, runs a link check and stops before it sends anything. The consultant reviews the output on a phone and approves the final step. The source files and credentials never move onto the phone.
2. An agency supervises a long test suite. An engineer starts the tests on an always-on workstation and leaves for a meeting. ChatGPT sends a notification when the task finishes or needs attention. The engineer then sends a focused follow-up and does not stream a remote desktop for an hour.
3. A founder works through an SSH development host. The desktop app connects to a saved SSH alias. Codex reads and edits the remote project under a least-privilege account. Before anyone approves a deployment command, the founder reviews the diff from another device.
4. A team moves work between machines. A person starts a chat on a laptop. Before the person closes the laptop, they use handoff (a function that moves a chat to another machine). Handoff moves the chat and its Git state to a connected remote host. Handoff needs a saved project for the same Git repository on the destination host. It does not move chats into a Codex cloud environment.

Host choice	Good fit	Main limitation
Everyday laptop	Short tasks and occasional remote checks	Sleep, lost network or a closed app ends access
Dedicated always-on computer	Longer jobs and repeatable automation	Needs patching and credential hygiene
SSH development host	Projects that already run remotely	Adds SSH identity and server administration

OpenAI says that on a Mac laptop, remote access can stay available when the lid is open and the power is connected. If the lid is closed, also connect an external display. If you choose Sleep, access stops. On Windows, Computer Use runs in the foreground. Keep the session signed in. Do not lock the screen. Leave the desktop to the task.

From agent output to client delivery

Codex remote control is for supervising work, not for delivering it. Problems start when you send a client a raw file path, a temporary preview URL or a terminal artifact. Links expire, and the next revision needs another email. Also, logs or secrets can go out by accident.

Keep production and delivery as separate steps:

1. Codex prepares the report, proposal, presentation or demo on the connected host.
2. A person reviews the result on a full screen and removes logs, .env files, drafts and internal notes.
3. Any command that publishes, deploys or sends something requires an explicit approval.
4. The approved files go out through a tool that is made for that job and has access control that fits the audience.

Deliverable	Where it can go	Access control
Proposal or report PDF	A document-sharing tool such as DocSend or Papermark	Required email, passwords and expiry dates (this depends on the plan)
Static demo site	Cloudflare Pages, Netlify or Vercel	Cloudflare Access, Netlify password protection (paid plans) or Vercel Deployment Protection
Code changes	A pull request in the client’s repository	Repository permissions and review rules

Codex can automate the repetitive packaging, but the decision to send something to a client stays with a person.

Troubleshooting Codex CLI remote control and safer operating habits

If Codex remote control fails, troubleshoot from the outside in. A reinstall can erase evidence, and it rarely fixes a problem with workspace policy.

1. Make sure that the host is awake, online and not set to sleep. Make sure that it runs the current ChatGPT desktop app.
2. Make sure that the phone has the latest ChatGPT app. Make sure that it is signed in to the same account and workspace.
3. On the host, open Settings > Connections. Make sure that the host allows other devices to connect.
4. If nobody used the connection on or after June 8, 2026, update both apps and pair again.
5. Complete every required SSO, MFA or passkey step.
6. If you see “Codex Mobile is disabled by your workspace admin,” stop local troubleshooting. Contact the admin.
7. After the connection works, review the sandbox, filesystem, network and command-approval settings separately.

Operating habit	Why it helps
Stop remote control when you do not need it	Shortens the time the host is reachable
Pair only devices you control	Limits who can control the host
Review connections after you lose or replace a phone	Removes old access paths
Keep client secrets outside broad working directories	Reduces accidental model and tool access
Require approval for deployment and publishing	Keeps a human decision point
Keep logs of important actions	Makes mistakes easier to investigate

When you sign out of ChatGPT, Remote Control turns off, but existing device pairings stay. After you sign back in, turn Remote Control on again. If you turn it on, select Add and see an error, restart the ChatGPT desktop app on the host. Then try again. For more symptoms and fixes, see Fix Codex remote control not working.

Summary

Codex CLI remote control works best as a supervised bridge to a trusted host. The experimental CLI command runs remote control for the local app server and creates short-lived pairing codes. Codex on mobile adds control from a phone and from other devices. Its setup starts in the desktop app, and an administrator can turn it off.

Keep the boundaries clear. Device discovery is not command approval. Pairing is not unrestricted filesystem access. A secure relay is not permission to expose an app server publicly. The sandbox, network rules, credentials and approval policy of the host stay at the center of your security model.

Email for use by your
AI apps and agents

Receive emails, send replies, store attachments.
Designed for quick integration into your workflow.

• 3 free mailboxes
• 3,000 emails in, 500 out a month
• 3 GB of file storage
• Malware and prompt-injection filter
• API, MCP and CLI access

Start Free→ Need help? Email us

No card required.