Codex in the cloud: fire-and-forget engineering
The CLI version of Codex is pair programming: you watch every move it makes. The cloud version is a different job description: delegation. You hand it a task, an agent spins up a sandboxed container on OpenAI's infrastructure, clones your repo, works to completion, and comes back with a pull request. You never see the machine it ran on. That one change quietly rearranges where the bottleneck in your workflow sits.
The loop, from the outside
Mechanically it is simple. You point Codex at a task (a GitHub issue, or a paragraph of intent) against a connected repo. It builds a fresh container, runs your setup script to install dependencies, then does what the local agent does: reads code, edits, runs tests, iterates. When it converges, it pushes a branch and opens a PR with a summary and the test output it saw. Your involvement collapses to two moments: writing the task and reviewing the result.
Everything between those moments is invisible, which is both the point and the price. There is no mid-flight steering. If the task was underspecified, you find out at review time, in the shape of a confident and wrong PR. Specification discipline that felt optional in an interactive session becomes the whole game.
What parallelism actually buys
On your machine, agents serialize on your attention. In the cloud they do not: kick off three tasks before a meeting, review three PRs after it. The unit of work stops being the session and becomes the queue, which is the idea behind running a fleet of Codex agents against a backlog. It only works because review is async: the agent does not need you present, so your calendar stops being the scheduler.
But delegation pays only on the right tasks: well-specified, verifiable by tests, low on tacit context. Dependency bumps with test fallout. Mechanical refactors. Coverage for an untested module. The bug with a clean reproduction. The moment a task needs a mid-course judgment call, fire-and-forget is the wrong shape. That is the standing limit of long-running autonomous agents, and a better model does not repeal it.
Your setup script is the product now
Here is what surprises teams: the ceiling on cloud Codex is the environment, not the model. The container is built from your setup instructions, and network access is typically restricted once setup completes. Anything you did not declare is simply absent. If the script cannot produce a working environment, the agent cannot run your tests. And an agent that cannot run tests does not stop; it keeps editing and returns changes it never verified.
A cloud agent that cannot run your tests is a confident diff generator, not a junior engineer. Confident diffs are the expensive kind.
Most repos' setup docs lie a little. They assume a globally installed tool, a database that happens to be running, an env var everyone exported years ago and forgot about. Local agents survive this because your machine papers over the gaps; a fresh container does not. So treat the setup script as CI-grade code: pin what matters, declare every dependency before the network goes away, fail loudly instead of limping. My test is blunt: if a new laptop cannot go from clone to green tests using only that script, neither can Codex.
Delegate accordingly. Fenced, test-verifiable work goes to the cloud; exploratory and judgment-heavy work stays interactive, where you can steer. And when a PR comes back weak, read the logs before blaming the model. Check whether the tests ever actually ran. In my experience that is where half the disappointing results come from, and it is the half you can fix this afternoon.