Coding agent sandbox escapes: a checklist after the Codex research.

A coding agent sandbox escape is not an alignment story. It is an access story. On 15 September 2026 Oren Yomtov of Accomplish published two techniques that broke out of the OpenAI Codex sandbox, one of them out of read-only mode, the strictest setting Codex offers. OpenAI had already fixed both. What stays relevant after the patch is the shape of the failure, and that shape applies to every coding agent your developers run.

The guardrail was enforced by the same process it was supposed to restrain.

#What Accomplish found

Codex runs model-generated commands inside a sandbox with several modes. Read-only is the strictest. Workspace-write is the normal mode, where the agent may change files in the project it was pointed at. Both techniques started inside those modes and came out with command execution on the developer's machine.

Overpatch targets the apply_patch tool in the open source Codex CLI. Per the write-up, the tool derived write permission from the paths inside a patch, granting access to the parent directory of each target. A patch naming /tmp fails, because that is a directory and not a file, but the parent it adds to the allowed scope is the root of the filesystem. A second entry in the same patch then appends a line to the developer's shell profile through a symbolic link inside the workspace, and that line runs the next time a terminal opens. In the researchers' words, one extra line in a patch hands the patch tool write access to the whole disk, in the normal agent mode, with no approval prompt.

Heapjack is the more interesting one. Codex Desktop ships a Node REPL tool that creates two JavaScript contexts, a trusted one and an untrusted one, inside a single Node process. A random token separates them: requests carrying it are treated as privileged. Because both contexts share one V8 heap, the untrusted side can call v8.getHeapSnapshot() and read that heap, then test the token-shaped strings it finds until the error responses reveal which one is valid. With the token in hand it writes requests to the shared output pipe, and the native parent process, seeing a valid token, does as it is told.

What that token authorised, per the disclosure: launching applications outside the sandbox, talking to Unix sockets including the Docker daemon, and editing the agent's own configuration file at ~/.codex/config.toml. The trigger was opening a malicious repository in read-only mode and letting the agent work.

Both contexts live in one Node process and share one memory heap, so the token is just a string sitting in memory the untrusted side can read.

That sentence, quoted by BleepingComputer in its 20 September report, is the whole finding. The token was not stolen from a vault or phished. It was read out of memory the attacker already had a handle on.

#The guardrail had its own credential

Treat that token as what it is: a non-human identity. It had a holder, a scope of authority and no expiry that mattered inside a session. Everything you would ask about a service account applies to it. Who can read it. What does presenting it allow. Would anyone notice it being presented by the wrong caller.

Posed that way the answers are uncomfortable. Any code the model ran could read it. Presenting it lifted the sandbox. Nothing separated the trusted caller from the untrusted one except possession of a string they both reached.

This is the shared service account problem moved inside a process. We covered the outer version before: an AI-run campaign that reached Domain Admins through one service account. Here the credential that decides what an agent may do lives where the agent's inputs live.

#Anatomy of the path

# Heapjack, per Accomplish's write-up
malicious-repo       # opened in read-only mode
  → node-repl        # trusted and untrusted contexts, one V8 heap
  → auth-token       # recovered via v8.getHeapSnapshot()
  → parent-process   # token validated, request honoured
  → host-execution   # unsandboxed, no approval prompt

Read the steps and count how many are memory-safety problems. None of them. The heap snapshot is a documented Node API. The token check worked exactly as designed. Every step is an access decision: what the untrusted side could read, what possession of a string was allowed to prove, and what the parent process would do on request.

The last step is the one to hold on to. A coding agent runs on a machine that also holds cloud credentials, SSH keys, registry tokens and a live Docker socket. Command execution there is not the end of a path. It is the start of a longer one that most organisations have never drawn.

#What a coding agent can reach from a laptop

Developer machines were never modelled as high-reach systems. They are treated as endpoints, with an EDR agent and a disk encryption policy, while the access that sits on them is inventoried nowhere. A coding agent changes that, because it adds an actor that reads untrusted content all day and acts on it without a person approving each step.

The credentials in reach are the ordinary ones. A cloud CLI profile with a long-lived key. A git token scoped far wider than the repository in front of it. An npm or PyPI publish token. A kubeconfig pointing at a shared cluster. Environment files from three projects, each with a database URL that still works. Any of them turns a local escape into an incident somewhere else.

The fix is not to ban coding agents. It is to stop treating the agent's own guardrail as the only boundary, and to shrink what sits behind it. Same argument as after GitSpawn ran code in seven coding agents from a repository's .git/config. Different mechanism, same question: what did the agent get to touch.

#What to check this week

1. Confirm the versions actually in use. The fixes are in Codex CLI 0.149.0 and Codex Desktop build 26.818.21641. Ask for the installed version rather than the policy, because coding agent tooling is usually installed per developer and updated per developer.
2. Write down which coding agents are running and who installed them. Codex, Claude Code, Cursor, Copilot agents, local CLIs. If this list comes from a survey rather than an inventory, that is itself the finding.
3. Inventory the credentials on one developer machine. Cloud CLI profiles, git tokens, registry tokens, kubeconfigs, .env files, SSH keys. Count them, then check how far each one still reaches.
4. Kill the long-lived ones first. Every static key you replace with a short-lived credential removes a step from the path above. Start with the registry publish tokens, because those reach your customers.
5. Check what the Docker socket gets you. Access to the daemon is usually equivalent to root on that machine. If an agent can reach the socket, note it as a privilege boundary that no longer exists.
6. Look at egress, not only execution. An escape that cannot reach the network is a much smaller event. Ask whether agent processes go out through a proxy you control, or straight out through the laptop.
7. Decide where the boundary is supposed to live. If the answer is the agent's own sandbox setting, you are relying on a control that runs in the same process as attacker-supplied input. A virtual machine, a container without the host socket, or a separate account are boundaries the agent cannot argue with.

Both of these were patched before they were published, which is how disclosure is supposed to work. The part that is not patched is the assumption underneath: that the agent's own restriction setting is the thing standing between a repository someone else wrote and the credentials on a developer's machine. Elmoz maps which of those credentials a compromised agent identity would actually reach.