Writing

Codex on your laptop, Codex in the cloud, and a third place

4 August 2026

Codex on your laptop keeps the agent in front of you and stops when the laptop does. Codex cloud takes a task away, runs it in its own isolated environment, and hands back a summary and a diff. The third place is the CLI itself on a machine you do not own, still in front of you, in a directory it shares with other agents and with your team.

“Local or cloud” sounds like a question about compute, and people ask it as though the cloud version were the same agent with a bigger machine behind it. It is not. The two are different products with different contracts, and the thing that actually differs is who is expected to be watching.

Local: you are in the loop, and you are the runtime

The CLI on your own machine is the tightest version of the loop. It sees the checkout you are looking at, it can run your tests with your environment variables, and you read every line as it happens. Nothing is faster to correct, because you are already there when it goes wrong.

It is also bound to the machine in every sense. The run ends with the lid. A second agent means a second checkout, or two agents writing over each other in one. And nobody else can see any of it without a call and a screen share.

Cloud: the task leaves, and a diff comes back

OpenAI describes Codex cloud as running tasks in isolated cloud environments, in parallel, started from the web, GitHub, Linear or Slack, with dedicated environments for the long ones and a summary and a diff at the end. Read that as a contract rather than as a feature list: you hand over a task, you get back a proposal, and the isolation is the design.

For a well specified job in a mature repository, that contract is excellent. Fix this flake, upgrade that dependency, port this pattern across forty files. You did not want to watch, you wanted a pull request, and the environment being disposable is exactly right.

It is the wrong contract for the case people describe to us most often, which is two or three agents building one application at the same time. Isolation makes the second agent unable to see the type the first one finished a minute ago, so it declares it again. On a young codebase the diffs collide on the generated files nobody owns. Reserving a file before you write it is that argument in full.

The third place: the CLI itself, on a machine you do not own

There is an option between the two that is easy to miss because it is not a different agent. It is the same Codex CLI, in a real terminal, on a cloud machine, still in front of you.

You keep what local gives you: the real CLI, the whole output, the ability to interrupt it mid sentence. You gain what cloud gives you: the run outlives the lid, and several agents work in one directory instead of one each, because a claim on each path keeps them from writing over each other. And you gain the thing neither has, which is that somebody else can open the link and be in the room while it happens.

The account stays yours. Murmell is not the agent and does not resell one; it starts the CLI you already pay for, beside Claude Code, in the same project directory. Switching between them leaves the directory, the reservations and the history where they are, because those belong to the canvas rather than to whichever CLI is attached to it.

How to choose, honestly

If the work is one bounded task and you want a pull request, delegate it. Codex cloud does that better than watching ever will, and it reaches into Slack and Linear where the work is already described.

If the work is a thing being built, by more than one agent or in front of more than one person, then the run needs to be somewhere everybody can reach and the agents need to share a directory. That is a different shape, and it is the one we build. Murmell compared with Codex cloud puts the same three questions to both, side by side.

Straight answers