The Codex sandbox escapes prove your agent's blast radius is your laptop

Your coding agent is running untrusted patches inside a sandbox on the same laptop that holds your SSH keys, your cloud tokens, your kubeconfig, and the GitHub credentials that push signed commits into production. Take a moment with that mental image. Comfortable? Good.

On September 15, 2026, Accomplish AI published the technical write-up of two sandbox escapes in OpenAI Codex. Researcher Oren Yomtov named them Heapjack and Overpatch. Both let code jump out of the Codex sandbox and run on the developer host with no approval prompt and nothing on screen. Reported to OpenAI on August 12, patched within eight days. Fast triage, and OpenAI earned that credit. The uncomfortable part is that the shape of the bug is going to keep happening, because the sandbox lives inside the thing it is supposed to contain.

The mechanics, kept to what the disclosure says

Heapjack and Overpatch had different root causes, per Accomplish's writeup, but the same outcome: arbitrary code executing on the developer's machine outside the approval flow that Codex normally shows for shell commands, network calls and file writes. No dialog fired. No log line surfaced. A user watching the agent work would have seen the same interface they always see, while a payload from a fetched dependency or a poisoned test fixture was already running as them.

Two independent escapes, one system, one review cycle. That is the number that matters. Not because OpenAI is uniquely careless (they patched within a week and a day), but because the sandbox model everyone in this space uses is a probabilistic bet against a determined attacker and a large surface area.

Why "on the same machine" is the wrong trust boundary

Look at what a coding agent inherits when it runs on your laptop:

• The SSH keys that push to your git host.
• The keychain entries and short-lived tokens that open pull requests, merge changes and kick off CI runs.
• Cloud credentials cached under ~/.aws, ~/.config/gcloud, ~/.kube.
• npm, PyPI and container-registry publish tokens.
• Whatever .envrc you loaded three sessions ago and forgot.

A sandbox escape in this context is not "the agent ran a stray command." It is "attacker-controlled code inherited your full developer identity, including the credentials that sign commits and trigger production deployments." That is a supply-chain path that starts on the laptop and ends in the release pipeline, wearing a legitimate signature the whole way.

GitHub's 2026 Actions security roadmap already cites tj-actions/changed-files, Nx and trivy-action as recent pipeline-targeting incidents. Those all travelled through the CI system itself. Heapjack and Overpatch open a second lane, one that skips CI entirely and compromises the human whose keys CI trusts. If your threat model stops at the runner, you now have a gap.

Approaches that move the blast radius somewhere less painful

There is no free lunch here, but there are architectures that put the compromise domain somewhere other than your developer identity:

• Container isolation wraps the agent in a namespace boundary. It shares the kernel, and any workspace mount usually punches a convenience hole straight back through the boundary. It stops the trivial cases and nothing more.
• microVM sandboxes give the agent its own kernel. This is the direction production CI runners have moved for the same reason: strong isolation cheap enough to spin up per task.
• Remote execution moves the whole runtime off the developer machine. The agent runs in a hosted workspace reached over an API, so an escape reaches a stateless VM the vendor recycles, not your keyring.

Each of these costs something. Remote execution loses low-latency filesystem work. microVMs cost RAM and start-up time. Containers still hand you a shared kernel. Pick your poison, but pick one that fails into a domain you can rotate cheaply.

What to change on Monday

You cannot wait for every agent vendor to redesign their sandbox. In the meantime:

1. Assume any coding agent on your laptop can eventually reach anything your shell can. Move long-lived tokens out of the environment and into a keychain that requires per-use approval.
2. Prefer agents that run in a remote or containerised workspace when the task allows it. Accept the latency.
3. Rotate credentials after any agent session that used shell tools or fetched network content. Yes, all of them.
4. Push CI toward OIDC-brokered short-lived credentials, so a stolen laptop token cannot pivot into production.

The kicker

Every agent vendor will tell you the sandbox is safe. Right up until the writeup goes live and the patch note ships. Trust the boundary, never the brochure.