Codex on your phone isn't AI on your phone: the async agent pattern, explained

OpenAI shipped two things today. One is a Codex mobile app, available on iOS and Android, free tier included.¹ The other is a ChatGPT safety update that detects risk drifting through a conversation rather than waiting for a single alarming sentence.² They are unrelated products that happen to share a launch date, and I want to focus on the first one, because the architecture is more interesting than the press release makes it sound.

Here is the thing worth understanding: when you tap a button in Codex mobile to "fix the failing test in my repo," nothing about that task runs on your phone. Your phone is a remote control. The actual work, the model, the code, the file system, the test runner, is happening in a sandbox somewhere in OpenAI's cloud. You close the app. The agent keeps going. You come back later and review what it did.

That pattern has a name I want to give you, because once you see it you will see it everywhere: thin client, remote agent. It's the dominant shape for serious agentic products right now, and it has consequences for how you think about cost, trust, and what "using AI on your phone" actually means.

The problem the pattern solves

Why agents don't run on devices. A coding agent isn't a single model call. It's a loop: read the task, look at the repo, propose a change, run the tests, read the failure, propose another change, run the tests again. Each step is a model call plus some real work in a real environment. On a typical task this loop runs for minutes, sometimes longer, and each iteration needs a sandbox where the agent can execute code without breaking anything else.

Your phone cannot host that. Not the model (codex-1 is a tuned version of o3, far too large to run on-device).¹ Not the sandbox (you do not want arbitrary AI-generated shell commands running on your personal device). Not the persistence (the task needs to keep going when you switch apps to answer a text).

So the agent lives elsewhere. The phone is just the surface where you start tasks, see progress, and review results.

The shape of the pattern

Three components, each living in a different place:

The client. Your phone, or your browser, or your IDE. Its job is narrow: take an instruction from you, send it to the dispatcher, then show you what comes back. It does not hold the model. It does not hold the code. It does not hold state about the task in any meaningful way. If you drop it in a lake, the task keeps going.

The dispatcher. A service that receives the task, decides what sandbox to spin up, hands the task to an agent, and keeps track of which task belongs to which user. This is the part you never see and almost never think about, but it is doing most of the operational work.

The sandboxed agent. For each task, a fresh isolated environment. Codex clones the relevant repository into that sandbox, gives the agent shell and file access inside it, and lets the agent run.¹ When the agent thinks it's done, the diff (the proposed code change) is reported back through the dispatcher to your client. The sandbox is then torn down.

The agent loop itself, read, plan, edit, run, observe, repeat, happens entirely inside that remote sandbox. The model calls inside the loop go from the agent to OpenAI's inference service and back. None of those round trips touch your phone.

A worked example

You're on a train. You open Codex mobile and type: "in my repo notes-app, the dark mode toggle doesn't persist across reloads — find and fix it."

Here is what happens, roughly, in the next few minutes:

1. Your phone sends the instruction and a pointer to your repo to the dispatcher.
2. The dispatcher allocates a sandbox in OpenAI's cloud. The sandbox clones notes-app from GitHub using credentials you previously authorised.
3. Inside the sandbox, codex-1 starts the agent loop. It reads the project structure, searches for "dark mode," finds the toggle component, reads the relevant code, forms a hypothesis (probably: the toggle state isn't being written to localStorage).
4. The agent edits a file, runs the test suite, reads the output. Maybe a test fails. It edits again. Tests pass.
5. The agent reports back through the dispatcher: "I changed these three lines in this file, here's the diff, here's what I think was wrong."
6. Your phone, which has been disconnected for the last six minutes because you went into a tunnel, reconnects. A notification appears. You open the app, read the diff, and either approve it (which opens a pull request) or send back feedback ("the localStorage key should be namespaced, try again").

The interesting part is step 4. You weren't there for it. Your phone was off. The agent did not need you. This is what "asynchronous" means in this context: the human is not in the loop while the loop is running.

The trade-offs

What you give up. Privacy, mostly. Your code is being cloned into someone else's sandbox to be read by a model. For open-source repos this barely matters. For proprietary code this is a real consideration and the reason enterprise versions of these products exist with different data handling guarantees.

You also give up offline capability entirely. There is no degraded mode. No connection, no agent.

And you give up the kind of fine-grained per-keystroke feedback you get from in-IDE assistants. Async means you commit to a task description and walk away. If the agent misunderstands, you find out minutes later, not seconds later.

What you get. The ability to start meaningful work from a device that could not possibly do that work itself. Parallelism across tasks (multiple sandboxes, one phone). And a model of human-AI collaboration that looks much more like "delegating to a junior engineer" than "autocomplete on steroids."

Adjacent patterns, and how to tell them apart

The thin-client-plus-remote-agent shape is not unique to Codex. GitHub Copilot Workspace, Cognition's Devin, and Cursor's background agents all do versions of this.³ The mechanics are broadly similar: queue a task, run it in a sandbox, review the diff.

What is genuinely distinct between them tends to be: how the sandbox is provisioned (per-task vs. long-lived), what tools the agent has inside it (just shell? a browser? a database?), how the agent reports intermediate progress, and how human review is gated. Those details matter for any specific use case, but the underlying pattern is the same one.

Worth distinguishing from a different pattern: in-process AI, where the model runs inside your editor or your phone and operates on local files in real time. Copilot's inline completions are in-process. Apple Intelligence on-device is in-process. These are not agents in the loop sense. They are fast suggesters. Different pattern, different trade-offs, different mental model.

When to reach for it

The async-remote-agent pattern is the right shape when: the task takes long enough that watching it run is wasteful; the agent needs a real execution environment, not just a model; and the work product is reviewable as a discrete artefact (a diff, a document, a deployed change).

It is the wrong shape when you need tight conversational iteration, when the data cannot leave your device, or when the task is so small that the overhead of spinning up a sandbox dwarfs the work itself.

The reason Codex on a free-tier phone is a strategically interesting move, and the reason I think you will see more of this shape, not less, is that once the agent is remote, the device becomes almost irrelevant. The same task can be started from a phone, a watch, a Slack message, or a CI hook. The agent doesn't care. It's already somewhere else.

Footnotes and links

Further reading

• OpenAI Codex product page: https://openai.com/index/work-with-codex-from-anywhere/
• ChatGPT sensitive-conversation update: https://openai.com/index/chatgpt-recognize-context-in-sensitive-conversations/

¶