Local Machine or Managed Container: The Difference That Actually Survives

Both tools now run in both places. What still differs is which environment each one treats as home — and home is where the sharp edges got filed off.

The sentence everybody repeats

Ask which of the two coding agents you should use and within a minute somebody will give you the architectural one-liner: Claude Code runs on your machine, Codex runs in OpenAI's cloud. It is the first difference every comparison leads with, and it is the one that shapes how people talk about both products — local tool versus hosted service, your shell versus somebody else's container.

The sentence is a reasonable summary of where each product started and where its defaults still sit. It is not a description of what either product is in August 2026, and the gap between the two matters, because most of the advice built on that sentence — about credentials, about reproducibility, about what the agent can reach — is advice about a boundary that has moved.

The argument here is that "local versus cloud" is the wrong axis to reason about. Both tools now run in both places. What actually differs is which environment each one treats as the default, and therefore which environment gets the attention, the tooling and the sharp edges filed off. That is a real difference with real consequences, and it is not the one people state.

Where each product started

Claude Code began as a terminal program. You install it, you run it in a repository, and it operates through the same shell you were already using — your Node version, your Python environment, your database socket, your SSH agent, your half-configured build. Anthropic's documentation describes it as running in your local environment with access to your files, git history and shell.

Codex began at the other end. OpenAI's original launch put each task in a separate cloud environment preloaded with a copy of your repository. The agent reads and edits files, runs tests and invokes checking tools inside that container, and hands you back command logs, test results and a diff. Most tasks, by OpenAI's own description, run between one and thirty minutes. You are not watching a shell; you are collecting a result.

Those two starting points explain almost every downstream difference in the two products' design, which is why the one-liner has stayed useful for as long as it has.

Both products crossed the line

Codex has had a local CLI since April 2025, and it is not a thin remote control. Its configuration file carries a sandbox_mode setting with values including workspace-write and danger-full-access, alongside an approval_policy that takes untrusted, on-request or never. Those settings exist because the thing being configured is a process on your machine touching your files. A tool that only ran in a managed container would not need a workspace-write mode.

Claude Code went the other way. It now runs sessions in hosted cloud environments as well as on your laptop, with the local machine attached as a resource the session can reach rather than as the place the session lives. The desktop application, the web interface and the hosted session model all describe the same shift: the agent is no longer necessarily a process in your terminal.

So the honest version of the architectural claim in 2026 is not that one runs locally and one runs remotely. It is that each product has a home environment and a visiting one, and they chose opposite homes.

What "home environment" actually buys

The distinction is not cosmetic, because the home environment is where the awkward cases get handled.

Running on your machine means the agent inherits everything your shell already has. That is the whole argument for it. The internal package registry your team authenticates to, the database on a local socket, the license server your build reaches, the environment variables your application will not start without, the four scripts in bin/ that only work because of something in your dotfiles — none of these need to be described to a tool that is already inside them. Every one of them is a configuration task for a tool that is not.

Running in a managed container means the agent inherits nothing, which is the whole argument against it and also the whole argument for it. Nothing it does can touch a file outside the workspace, because there are no files outside the workspace. Network access is off unless you turn it on. A destructive command destroys a container that was going to be discarded anyway. The blast radius is bounded by construction rather than by a permission prompt somebody has to read.

Local agent, your machine
  ~/.aws/credentials          reachable
  ~/.ssh/id_ed25519           reachable
  psql on a unix socket       reachable
  internal npm registry       authenticated already
  a stale node_modules        reachable, and it will use it

Managed container
  repository copy             reachable
  network                     off unless enabled
  your credentials            absent unless injected
  your local database         absent
  your build cache            absent, cold every run

Read those two columns as a single trade rather than as a scoreboard. The left column is the reason a local agent can finish a task that touches your real infrastructure without a day of setup. It is also the reason a mistake lands on your actual credentials. The right column is the reason a container is safe to leave unattended, and the reason a task that needs your internal registry fails in it until somebody plumbs the registry through.

The reproducibility asymmetry

This is the consequence most teams meet first, and it does not announce itself as an architecture problem.

When a local agent reports that the tests pass, what it has established is that the tests pass on that machine, in that shell, with whatever was already installed. That is the same claim a developer makes when they say it works locally, and it has the same shelf life. The agent has no more insight into your leftover environment variables than you do.

When a container reports that the tests pass, the claim is narrower and more portable: they passed in an environment built from a declared starting point. If the container is built from your repository's own setup, a passing run is evidence the setup is complete, because nothing else was available to make it work. That is a genuinely stronger claim, and it is the one thing the managed model gives you that no amount of local permission tuning can.

The corollary is uncomfortable in the other direction. A container that fails on a step your laptop sails through is usually not a container problem. It is an undeclared dependency your machine has been quietly supplying for months, and the container is the first thing to notice.

Latency, and what it does to how you work

A local agent's edit-run-read cycle is bounded by your disk and your test suite. A managed task's cycle includes provisioning, cloning, installing and returning — the one-to-thirty-minute window OpenAI describes. Those are not the same interaction even when the underlying model is equally capable.

Under a second, you supervise. You watch the diff, you interrupt when it goes somewhere you did not intend, you steer. Over several minutes, you cannot: you have gone to do something else, and the only thing you will actually read is the result. The environment therefore selects the working style before you have made any decision about working style, which is why the architectural difference shows up in your calendar rather than in your configuration file.

This is also why the two products' feature sets diverged the way they did. A tool built for supervision invests in interruption, granular permission prompts and mid-task steering. A tool built for delegation invests in returning a reviewable artifact: logs, test output, a diff you can read without having watched it being made.

Deciding by the shape of the work

The useful question is not which product is more capable. At the frontier the models are close enough that harness design, not model choice, decides most outcomes. The useful question is what the task needs from its environment.

Work that needs your real infrastructure — reproducing a bug that only appears against the staging database, wiring up a service that reads from a local socket, anything where the failure lives in your environment rather than in the code — wants the local model, because the alternative is recreating your environment somewhere else in order to look at it.

Work that must be verifiable by somebody who did not watch it — a dependency bump across twelve repositories, a mechanical migration, anything that will arrive as a pull request — wants the container, because the claim you need is that it works from a clean start, and only a clean start can make that claim.

Work that is exploratory, where you do not yet know what you are looking for, wants whichever one you can interrupt fastest, which in practice means the local one.

Test the boundary rather than trusting the label

Because both products now run in both places, the only reliable way to know which environment you are in is to ask the environment. Before you rely on an agent reaching something, have it check.

#!/usr/bin/env bash
# Ask the environment what it actually is, rather than assuming.
echo "host:    $(hostname)"
echo "pwd:     $(pwd)"
echo "user:    $(whoami)"

for p in ~/.ssh ~/.aws ~/.config/gh; do
  [ -e "$p" ] && echo "present: $p" || echo "absent:  $p"
done

# Egress: a container with networking off fails here, quickly.
curl -s -m 4 -o /dev/null -w 'egress:  %{http_code}\n'   https://example.com || echo "egress:  blocked"

# The thing people assume is there and often is not.
command -v psql >/dev/null && echo "psql:    yes" || echo "psql:    no"

Four lines of output settle an argument that otherwise runs for a week. If the credentials are absent and egress is blocked, you are in a container and should stop planning tasks that assume otherwise. If they are present, you are on a machine that has something to lose, and the permission model is the only thing standing between the agent and it.

What the difference costs you once you rely on it

Relying on the local model means your safety story is a permission prompt, and a permission prompt is only as strong as the attention of whoever is answering it. Relying on the managed model means your setup story has to be complete and declarative, because nothing undeclared will be there. Neither cost goes away by choosing carefully; they are the price of the respective benefit.

The teams that handle this well tend to stop treating it as a product choice at all. They decide per task which environment the work belongs in, and they accept that the tool whose home that is will be the more comfortable one to use there.