Remote Control for Coding Agents: Codex vs. Claude Code vs. GitHub Copilot

A coding agent does not become useful away from your desk merely because it can run for a long time. It also needs a way to tell you what happened, ask for a decision, receive another instruction, and remain attached to the environment where the work began.

That is the promise of remote control in Codex, Claude Code, and GitHub Copilot. You start work on a Mac or Windows PC, walk away, and use a phone or another computer to supervise the same local environment. The repository does not move to your phone. Shell commands, file edits, local tools, credentials, and tests still run on the host computer. The remote device is the control surface.

This distinction matters because remote control is not the same as cloud delegation:

• Remote control: the agent runs against your existing machine and local setup; another device lets you guide it.
• Cloud delegation: the task runs in a vendor-managed environment, usually from a cloned repository and a separate set of credentials and tools.
• Remote desktop: you operate the whole graphical desktop. Agent remote control exposes the conversation, approvals, progress, and results instead of streaming every pixel.

Use remote control when the local environment is valuable: a large repository that is already indexed, private dependencies, local MCP servers, signed-in development tools, device simulators, databases, or hardware that would be awkward to reproduce in a cloud sandbox.

The three products use different host models

All three preserve local execution, but they are not interchangeable. Codex treats the desktop app as a connected host. Claude attaches remote access closely to a Claude Code process or server. Copilot attaches it to an interactive CLI session and exposes that session through GitHub's agent interfaces.

Set up Codex Remote

Codex Remote is part of the ChatGPT desktop and mobile experience. It does not turn an arbitrary Codex CLI or IDE-extension process into a mobile session. The host must be running the current ChatGPT desktop app on macOS or Windows, signed in to the same ChatGPT account and workspace as the phone.

On the host computer:

1. Open Settings → Connections → Control this Mac or PC.
2. Select Set up or Add, approve remote access, and complete any account verification.
3. Scan the displayed QR code with the phone that will control the host.
4. Finish pairing in the ChatGPT mobile app.
5. Review whether the app should keep the host awake and whether Computer Use or browser access should be available.

On the phone, open Remote, select the connected computer and project, then open an existing chat or start a new one. From there you can send follow-up instructions, answer questions, approve actions, and inspect responses, changed files, diffs, tests, terminal output, and screenshots.

The host supplies the actual environment. Its files, credentials, permission profile, plugins, skills, MCP servers, browser state, and local tools remain the ones Codex uses. If the computer sleeps, loses its network connection, or closes the desktop app, remote access stops until the host returns. OpenAI documents the complete setup and host behavior in Codex Remote and the Remote connections guide .

This model is especially useful when a task crosses the terminal boundary. A remote Codex chat can report a test result, show a diff, use configured browser or computer tools, and ask you to approve the next action without requiring you to remote into the entire desktop.

Set up Claude Code Remote Control

Claude Code exposes a local CLI or VS Code session through claude.ai/code and the Claude mobile app. The most direct way to start a named interactive session is:

cd ~/projects/payments-api
claude --remote-control "Payments regression"

If Claude Code is already running, enable remote control without abandoning the conversation:

/remote-control Payments regression

The shorter /rc alias also works. Claude displays a session link and, on supported CLI flows, a QR code. Open the link in a browser, scan the code with the Claude app, or find the named session in the session list. The local terminal and remote interface stay synchronized, so you can alternate between them.

Claude also provides a server mode:

cd ~/projects/payments-api
claude remote-control --name "Payments API"

Server mode waits for remote connections and can serve sessions without a normal local interactive conversation. It is useful on a dedicated development machine; claude --remote-control is simpler when you want to keep typing in the terminal as well.

The session retains the local filesystem, project instructions, MCP servers, tools, and configuration. The remote client can also show running subagents and workflows, and current versions support sending images or files from the phone or browser into the local session. Some terminal-oriented commands and interactive pickers remain local-only, so remote control should not be treated as a byte-for-byte terminal replacement.

The computer and Claude Code process must remain available. Claude uses outbound encrypted connections rather than opening an inbound port on the machine, and it can reconnect after ordinary sleep or network interruptions once the host returns. Requirements, supported authentication, current limitations, and troubleshooting are documented in Claude Code Remote Control .

Set up GitHub Copilot CLI remote control

For a new interactive Copilot CLI session, start with:

cd ~/projects/payments-api
copilot --remote

For a session that is already running, enter:

/remote on

Copilot displays the remote access details. Open the session link, visit the recent agent sessions at GitHub.com, or open Agent sessions in GitHub Mobile. Running /remote without an argument shows the current state and access details; /remote off disconnects remote control.

If every interactive session should be remotely accessible, Copilot supports a settings entry:

{
  "remoteSessions": true
}

The command-line flags still take precedence, so copilot --no-remote disables access for one session. A useful companion command is:

/keep-alive busy

This prevents the host from sleeping while Copilot is working or waiting for your answer. Other keep-alive durations and modes are available, but busy is a sensible default because it does not keep an idle computer awake indefinitely.

From GitHub.com or GitHub Mobile you can send prompts, respond to questions and permission requests, approve or reject plans, change session mode, and cancel current work. Slash commands are not generally available in the remote interface, so perform session configuration locally before leaving. Remote control works only for interactive sessions, not scripted invocations that use a one-shot prompt option.

For organization-provided Copilot seats, administrators may need to set the Store local sessions in the Cloud policy to View and control. The repository itself does not have to be hosted on GitHub, although repository detection affects where the session appears. GitHub documents the full workflow in Steering a Copilot CLI session from another device and explains its security and policy model in About remote control of Copilot CLI sessions .

Practical workflow 1: supervise a long test run

The weakest remote prompt is “run the tests.” It gives the agent no stopping rule and may produce a flood of low-value output on a small screen. Define the scope, escalation rule, and final summary before leaving:

Run the integration tests for the payments package. If a test fails, diagnose the likely cause but do not edit files yet. Notify me when the run finishes or when you need a decision. Summarize only the failed tests, elapsed time, and the next recommended action.

From the phone, check whether the run is progressing rather than repeatedly asking for status. When the agent reports a failure, send a bounded follow-up:

Reproduce only the first failure, identify the smallest likely fix, and show me the proposed change before editing.

This pattern works in all three products. The advantage is not that the phone runs tests; it is that a test suite can continue using the workstation's dependencies and compute while you remain available for the one decision that matters.

Practical workflow 2: approve actions without granting blanket access

Remote approvals remove a common source of idle time. They should not remove the safety boundary.

Before stepping away, tell the agent what is in scope:

You may edit files under src/payments and run the focused test suite. Ask before installing packages, changing configuration, accessing credentials, modifying database state, or touching files outside that directory.

When an approval arrives, read the exact command, path, or URL. Prefer a narrow approval for the current action over a persistent “allow all” rule. If the request is surprising, deny it and ask:

Explain why this action is necessary and propose an alternative that stays inside the existing project permissions.

Remote control is valuable precisely because the human can remain in the loop. Treating every mobile notification as a button to tap defeats that design.

Practical workflow 3: steer after new information arrives

Imagine a support message arrives while the agent is investigating a checkout bug. You learn that the failure affects only customers using a particular currency. Send that fact into the existing session instead of starting over:

New evidence: the failure is reported only for JPY checkouts. Re-evaluate your current hypothesis. Do not discard completed work; state what this changes, inspect currency-specific rounding, and continue with the smallest focused reproduction.

The local session already holds the repository context, command output, and working hypothesis. Remote steering lets you alter direction without paying the coordination cost of reconstructing the task in a separate cloud environment.

Claude's remote interface can additionally accept a phone photo or file in supported versions, which is useful for forwarding a screenshot or log. Codex can use the connected host's configured browser and Computer Use capabilities. Copilot keeps the workflow close to GitHub's session and plan controls. The best surface depends on where the new evidence originates and which local tools the investigation requires.

Practical workflow 4: finish with a reviewable checkpoint

Do not end a remote session with “looks good.” Ask for evidence that will still be useful when you return to the workstation:

Stop after the focused tests pass. Give me: the root cause, files changed, tests run with results, any remaining risk, and the exact diff sections I should review at my desk. Do not commit, push, deploy, or open a pull request.

This creates a deliberate handoff from mobile supervision back to desktop review. Remote control is excellent for maintaining momentum; a large diff, visual regression, migration, or production action may still deserve a full-size screen and local attention.

Operational and security limits

Remote control extends the reach of a local agent, so the host's security posture matters more, not less.

• The host remains the execution boundary. Local credentials, tools, filesystem access, and network permissions are still available according to the host configuration.
• The host must remain reachable. Sleep, shutdown, a closed agent process, or a prolonged network loss can interrupt access. Use the product's keep-awake option where appropriate, preferably on power.
• Remote access is account-bound. Use multi-factor authentication and respect workspace or enterprise policy. Pair only devices you control and remove stale connections.
• Approvals still require judgment. A phone makes approval convenient, not inherently safe. Verify commands and side effects before accepting them.
• Conversation data is relayed. The local execution remains local, but prompts, responses, tool events, permission requests, and related session data must pass through the vendor's service to reach the remote interface. Review organizational data policies before enabling the feature.
• Do not expose local agent servers yourself. Use the supported relay and pairing flow. If you separately connect Codex to an SSH host, use normal SSH hardening, a VPN where necessary, and least-privilege accounts.

A dedicated always-on development machine can make remote work more reliable, but it also concentrates credentials and capabilities. Install only the repositories, tools, plugins, and secrets the agent actually needs. Keep destructive production access behind additional controls.

Which remote control experience should you choose?

Choose Codex Remote when you already work in the ChatGPT desktop app and want a mobile command center spanning chats, projects, diffs, tests, screenshots, browser activity, and other host capabilities. It is the broadest connected-computer model of the three, but the desktop app—not a standalone CLI session—is the host.

Choose Claude Code Remote Control when the terminal conversation itself is the center of work. It provides a direct bridge to a running Claude Code CLI or VS Code session, preserves local tools and MCP servers, supports browser and mobile clients, and exposes richer session-specific behavior such as named server mode and synchronized subagents.

Choose GitHub Copilot CLI remote control when your workflow already revolves around Copilot CLI and GitHub. Its remote interface is particularly explicit about responding to permissions and plans, changing modes, cancelling work, and using GitHub Mobile or GitHub.com as the control surface. Organization policy can be the deciding constraint.

The larger change is common to all three products: leaving your desk no longer has to pause local agent work. The useful pattern is not unattended autonomy. It is asynchronous supervision—give the agent a bounded task, let the workstation execute it, remain reachable for decisions, and return to a documented, reviewable checkpoint.

Further reading

• OpenAI — Codex Remote
• OpenAI — Remote connections
• Anthropic — Claude Code Remote Control
• GitHub — Steering a Copilot CLI session from another device
• GitHub — About remote control of Copilot CLI sessions