Walking away from the desk does not mean moving the development environment to your phone.
Codex Remote is better understood as a way to reach work that is already running somewhere else. The phone can provide prompts, approvals and steering while the project stays on a Mac, a Windows workstation or, through a desktop host, an SSH devbox.[1][2]
Move control when control is what you are missing. Moving execution is a separate decision.
Figure 1 | Remote control surface and execution topology.
The host remains the anchor
By 25 June, Codex Remote was generally available with one-to-one QR pairing between iOS or Android devices and Mac or Windows hosts. From ChatGPT mobile, you could start or continue work on a connected host, inspect progress and approve actions.[1]
The host still matters because that is where the live working context is anchored. A Mac project keeps its local files and tools. A Windows workstation keeps its own setup. If the desktop host is connected to an SSH development box, the work can continue against that remote environment instead.[2]
The phone is for the interruptions that need you: answer a question, correct the direction, approve a command, or inspect a diff, terminal output, screenshots and tests.[2] Queue and Steer still mean the same thing they do at the desk. The surface changed; the control semantics did not.
There is no clever workaround for a sleeping host. If the connected machine loses power, network access or the desktop app, Remote has nothing live to reach. For longer-running work, host availability is an operational prerequisite, not a minor setup detail.[2]
Appshots sit outside that remote path. When you are still at the Mac and the missing context is simply in another application, pressing both Command keys can send the frontmost window to Codex with a screenshot and available text.[1][4] An error dialog, API reference, preview or settings panel can often be handed over faster than it can be re-described. Appshots are a one-off context capture, not screen sharing, and text coverage depends on what the source app exposes.[4]
When execution belongs on the devbox
If the project already lives on a managed devbox, leave it there. The repository, approved dependencies, credentials or security policy may already belong to that environment, and copying the setup back to a laptop only creates another environment to maintain.
Remote SSH lets the Codex desktop app work inside that environment. OpenAI made it generally available on 14 May, with the desktop app detecting hosts from SSH configuration and creating projects on the remote machine.[2]
The topology is therefore:
Phone → connected desktop host → SSH devbox
The phone controls the connected desktop host. The SSH hop connects that host to the environment where the project runs.
Before putting Codex on top of the connection, make ordinary SSH predictable. ssh devbox should work cleanly, the host should resolve through ~/.ssh/config, and the remote login shell should expose the Codex command and environment it needs.[3] Adding an agent does not turn a broken SSH path into a healthy one.
Keep the normal SSH security model as well: trusted keys, least-privilege accounts and no extra authority just because an agent is now using the connection.[3]
Handoff handles a different movement. The 18 June release added thread handoff between local and remote hosts, allowing a thread to continue in a matching project on another connected host. Codex could also coordinate the transfer.[1]
A laptop can start the thread and an always-on workstation can take over later. The destination still needs the corresponding project. Handoff moves the thread to another prepared host; it does not conjure the same environment on an arbitrary machine.[1]
Figure 2 | Which Codex control path should you use?
GUI work has a smaller safety envelope
Terminal work can sit quietly in the background. Desktop automation cannot be treated quite so casually.
On macOS, the 21 May update added Remote Computer Use for locked machines. A qualifying active, trusted Computer Use turn could continue briefly after the Mac locked. The authorisation was short-lived, displays were covered while the desktop was available to the task, local keyboard or pointer input caused a relock, and the flow fell back to manual unlock when the conditions were not satisfied.[1][5]
Locked use keeps an already-running GUI step from being cut off by automatic screen locking. It is not a general remote-unlock feature.
Windows gained Computer Use and Remote support on 29 May, with Computer Use operating in the foreground.[1] While Codex is clicking through a Windows application, that desktop is part of the active task. Treating it as spare screen space at the same time is asking two operators to share one mouse.
Use the shortest route that reaches the work
A project on an SSH devbox gives the full picture without requiring every feature at once. Verify the ordinary engineering path before leaving: SSH works, dependencies load and tests can run. Let Codex start inside the devbox. Once you are away from the machine, use the phone only when the task reaches a human decision. Approve what needs approval, Steer if the investigation drifts, and review the diff and tests when there is something worth reviewing.
If the task needs a GUI, the host’s Computer Use rules still apply. A locked Mac gets only the scoped locked-use path. If the thread later needs a different host, that is when Handoff becomes relevant.
Sandboxing, approvals and host permissions still apply across these routes.[3][5] Remote changes where you can intervene; it does not erase the authority boundaries around the work.
Context trapped in another Mac app calls for Appshots. A project that already runs happily on the local host can stay local. For a small edit while you are sitting at the computer, the original project is usually the simpler path.
Each extra layer creates another place for sleep, network state, permissions or environment drift to fail. There is no prize for making the route look more agentic.
When the setup starts growing branches, identify what is actually missing: context, human control, or a suitable execution environment. Add that layer and stop. If the local path already works, leave it alone.
References
- OpenAI, ChatGPT & Codex changelog, relevant updates through 25 June 2026. https://developers.openai.com/codex/changelog
- OpenAI, Work with Codex from anywhere, 14 May 2026. https://openai.com/index/work-with-codex-from-anywhere/
- OpenAI, Remote connections, living documentation; used here only for SSH setup, security mechanics and connection behaviour. https://developers.openai.com/codex/remote-connections
- OpenAI, Appshots, living documentation; used here only for capture mechanics and context boundaries. https://developers.openai.com/codex/appshots
- OpenAI, Computer Use, living documentation; used here only for operation and safety mechanics. Historical release dates are taken from [1]. https://developers.openai.com/codex/computer-use