Codex Sandbox Escape: What to Check Before Opening an Untrusted Repository

Updating Codex is necessary. It is not the same as making an unknown repository trustworthy.

Two recently disclosed sandbox escapes make that distinction concrete:

• Overpatch used attacker-controlled patch paths to widen where apply_patch could write.
• Heapjack targeted the boundary between sandboxed JavaScript and a privileged native helper in Codex Desktop.

The researchers reported both issues to OpenAI on August 12, 2026 and say both were fixed within eight days. OpenAI's public Codex CLI 0.149.0 changelog independently records a fix that prevents apply_patch from widening write permissions.

The minimum version check

Run this before opening an unfamiliar repository:

codex --version

The current evidence supports these minimums:

Surface	Minimum	Evidence boundary
Codex CLI	0.149.0	OpenAI's release record includes the apply_patch permission fix.
Codex Desktop	build 26.818.21641	This threshold is reported by the researchers and repeated by BleepingComputer.

Use a later stable build when available. Do not read this table as a claim that every possible sandbox weakness has been eliminated.

Why updating is only the first gate

A coding agent does more than display source code. Depending on its permissions and tool setup, it may:

• read repository instructions and configuration;
• launch package managers, test runners, hooks, or build scripts;
• edit files in the workspace;
• call MCP servers or other installed tools;
• inherit access to credentials, sockets, or network destinations.

That means “take a quick look at this repository” is an execution decision, not merely a reading decision.

Patching fixes a known implementation bug. It does not remove malicious repository content, unsafe dependencies, exposed secrets, overpowered tools, or an operator approving the wrong action.

A safer untrusted-repository preflight

1. Separate the repository from valuable state

Use a disposable directory or VM that does not contain:

• production .env files;
• SSH keys or reusable access tokens;
• cloud credentials;
• browser profiles or session cookies;
• production deployment scripts with active credentials;
• writable mounts into important workspaces.

Do not treat “read-only” as permission to expose secrets. Heapjack matters precisely because a nominally restrictive mode did not contain the full attack path described by the researchers.

2. Identify the exact Codex surface

CLI, Desktop, IDE integrations, bundled binaries, and package-manager installs can resolve to different versions and helpers.

Record the surface and version you are actually testing:

codex --version
Get-Command codex -All | Select-Object Name, CommandType, Source, Version

A passing CLI check does not prove that a Desktop or IDE path uses the same components.

3. Start without repository-controlled execution

Before running installs, builds, tests, or hooks:

1. Inspect the top-level file names.
2. Read repository instructions as untrusted input.
3. Review package scripts and tool configuration.
4. Identify symlinks, submodules, generated binaries, and external tool definitions.
5. Decide which single command, if any, is justified next.

Do not start with npm install, a bootstrap script, or “fix everything.” Those actions dramatically expand the code and tools involved.

4. Use the smallest capability set

Begin with no network and no write access when the task permits it. If a later step needs one capability, grant that capability for a bounded task instead of widening the whole session.

Keep these decisions separate:

• Can the agent ask for approval?
• Can the process read or write this path?
• Can it reach the network?
• Can an installed tool act outside the repository?

An approval policy and a sandbox policy are not interchangeable.

5. Verify the artifact outside the agent

Do not accept “done” or exit code 0 as proof.

For any permitted edit, independently check:

• the exact changed-path list;
• unexpected files outside the intended directory;
• symlink targets;
• the required output's existence and hash when useful;
• whether credentials, environment data, or unrelated files appeared in logs.

If the required artifact is absent, the task failed even if the final message says it succeeded.

Windows failures are a separate problem

Security patching and Windows sandbox troubleshooting should not be collapsed into one repair.

For example, CreateProcessWithLogonW failed: 1385 points to a Windows logon-right boundary for the sandbox user. Helper-not-found, setup refresh, UAC errors, token setup failures, read-only workspaces, and child-process denials occur at different gates.

I keep the complete Windows classification flow, redacted evidence packet, rollback boundary, and source list in this Codex Windows sandbox failure clinic. There is also a browser-local sandbox triage tool that classifies the first observed error without uploading logs.

A practical stop rule

Stop the run when any of these is true:

• the resolved Codex version is below the required patched version;
• the repository needs credentials before its purpose is understood;
• a script asks for broader filesystem or network access than the task requires;
• the first error changes after several settings are modified at once;
• the agent reports completion but the required artifact cannot be independently verified;
• the only proposed fix is to disable the sandbox or use unrestricted host access.

The safe response is not “try harder.” It is to preserve the first evidence, reduce the environment, and decide whether the repository deserves any execution authority at all.

Sources

• OpenAI Codex CLI 0.149.0 release
• Accomplish: Escaping the OpenAI Codex sandbox, twice
• BleepingComputer: Researchers escape OpenAI Codex sandbox

Disclosure: This article was drafted with AI assistance and checked against the cited sources. Product release evidence, researcher claims, and operational recommendations are labeled separately.

Comments

[Brian · AI News]

The version check is the right first filter, and it is easy to treat as the whole story. Overpatch and Heapjack were real, they got patched, and pinning Codex CLI to at least 0.149.0 before you open someone else's repo should be non-negotiable. What still matters after that patch is the identity attached to the sandbox: a mounted home directory, a forwarded SSH agent, or cloud credentials in the environment outlive a fixed write boundary. I clone into a clean worktree, drop the env, and read install scripts before the agent is allowed to run them. Updating the tool makes these two escapes harder. It does not make an unknown repository trustworthy.