{"slug": "researchers-escape-openai-codex-sandbox-to-run-commands-on-host", "title": "Researchers escape OpenAI Codex sandbox to run commands on host", "summary": "Security researchers at Accomplish AI found two sandbox escapes in OpenAI's Codex coding agent, including one called Heapjack that achieves unsandboxed remote code execution on a developer's machine from Codex's strictest read-only mode with no approval prompt, according to researcher Oren Yomtov. Both flaws were reported to OpenAI on August 12 and fixed within eight days. The second flaw, Overpatch, abuses Codex's apply_patch tool in workspace-write mode to write outside the project folder, including appending a line to .zshrc via a symlink so the next terminal session runs attacker code unsandboxed.", "body_md": "Security researchers found two ways out of the OpenAI Codex sandbox, one of them capable of running commands on a developer's machine from Codex's most locked-down mode, with no approval prompt and nothing shown on screen.\n\nBoth flaws were reported to OpenAI on August 12 and fixed within eight days, according to Oren Yomtov of Accomplish AI.\n\nThe more serious of the two, which the researchers call Heapjack, turns a routine action into remote code execution: open someone else's repository in Codex, ask it a question about the code, and whoever wrote that repository gets unsandboxed command execution on your computer.\n\nCodex is OpenAI's coding agent, available as a command-line tool and a desktop app. Like rival agents, it runs the model's actions inside a sandbox so that untrusted code cannot touch the wider system. Both escapes work by defeating that boundary from the inside.\n\n## Heapjack\n\nThe Heapjack technique, as described in [Yomtov's writeup](https://www.accomplish.ai/blog/escaping-the-openai-codex-sandbox-twice/), targets a component called *node_repl*, which Codex Desktop writes into the global '*~/.codex/config.toml'* file at install time.\n\nThere is no opt-in and no setting to turn it off, and because the entry lives in the shared config, plain Codex CLI users inherit the same tool without ever being asked.\n\n*node_repl* runs a single Node.js process that holds two separate JavaScript execution contexts. One is trusted and contains OpenAI's own code. The other is untrusted and runs the agent's code. The trusted context proves it is trusted by presenting a random token generated fresh on each run.\n\nThe problem is that 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.\n\nThe untrusted code takes a snapshot of the heap with '*v8.getHeapSnapshot()'* and tries every string shaped like a UUID. A wrong guess returns \"not authorized.\" A correct token with a bad argument returns a real validation error, which tells the attacker the token is right.\n\nWith the token, the untrusted code writes its own request onto the same pipe the trusted context uses to talk to a native, unsandboxed parent process.\n\nThe parent checks the token, sees a valid one, and does the work. The proof of concept used the system's 'open' command to launch an application outside Codex's process tree entirely. The same access reaches any Unix socket, a Docker daemon socket being the obvious target, and a tool for editing the global config file.\n\nAll of this runs at read-only, the strictest sandbox mode, where the agent is not supposed to write anything at all.\n\n## Overpatch\n\nThe second flaw, Overpatch, sits in the open-source Codex CLI. In workspace-write mode, the agent may only write inside the project folder, and a shell command aimed at the home directory is refused.\n\nThe researchers got Codex's own patch tool, apply_patch, to write there anyway.\n\nThe tool grants write access to the parent folder of each path named in a patch. Name '/tmp', and it grants write access to the root of the disk.\n\nThe working exploit uses a patch with two changes: one that names '/tmp' and does nothing useful except widen the permission, and one that appends a line to '.zshrc' through a symlink into the home directory.\n\nRemove the first change and the write is refused. With it, the next terminal the developer opens runs the attacker's line unsandboxed.\n\n## The same underlying mistake\n\nBoth bugs share a shape: the enforcement mechanism was living inside the thing it was supposed to be enforcing. *apply_patch* worked out its own permissions from attacker-supplied input. *node_repl* kept the secret separating trusted from untrusted code in the same memory as the untrusted code.\n\nIn each case the sandbox was told, from the inside, to let something through.\n\nThe class of bug is not new. In July 2026, [Pillar Security researchers demonstrated](https://www.bleepingcomputer.com/news/security/cursor-codex-gemini-cli-antigravity-hit-by-sandbox-escapes/) the same idea across Cursor, Codex, Gemini CLI and Google's Antigravity, where an agent that stays inside its sandbox writes a file a trusted tool outside the sandbox later runs.\n\nReacting to Yomtov's post on X, one commenter [wrote that](https://x.com/0zSchnack/status/2100164179399242043) \"V8 contexts isolate globals, not memory, so the sandbox was really a promise the heap never agreed to.\" Another called the trust boundary \"[a room divider](https://x.com/ctfstudent/status/2100281489774526867).\" The default-enabled behavior drew its own scrutiny, with one asking why a privileged token was reachable from untrusted JavaScript at all.\n\n## What to do\n\nOpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0, according to Accomplish.\n\nUsers should update to those versions or later. Yomtov credited OpenAI with resolving both issues within eight days of his report.\n\nBleepingComputer reached out to OpenAI for comment prior to publishing.\n\n## \n[Build your security blueprint for AI-powered attacks](https://hubs.li/Q04x67m50)\n\nJoin Mikko Hyppönen and security leaders from the NFL, CHANEL, and Atlassian for a two-hour digital summit on what AI-speed attacks change, what defenders should stop doing, and how to validate, decide, fix, and re-validate at machine speed.\n\n[Save your seat](https://hubs.li/Q04x67m50)", "url": "https://wpnews.pro/news/researchers-escape-openai-codex-sandbox-to-run-commands-on-host", "canonical_source": "https://www.bleepingcomputer.com/news/security/researchers-escape-openai-codex-sandbox-to-run-commands-on-host/", "published_at": "2026-09-20 14:35:11+00:00", "updated_at": "2026-09-20 14:52:51.617485+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "ai-tools", "developer-tools"], "entities": ["OpenAI", "Codex", "Accomplish AI", "Oren Yomtov", "Heapjack", "Overpatch", "node_repl", "apply_patch"], "alternates": {"html": "https://wpnews.pro/news/researchers-escape-openai-codex-sandbox-to-run-commands-on-host", "markdown": "https://wpnews.pro/news/researchers-escape-openai-codex-sandbox-to-run-commands-on-host.md", "text": "https://wpnews.pro/news/researchers-escape-openai-codex-sandbox-to-run-commands-on-host.txt", "jsonld": "https://wpnews.pro/news/researchers-escape-openai-codex-sandbox-to-run-commands-on-host.jsonld"}}