How to use Codex to evaluate sandbox boundaries
Oren Yomtov tested Codex patch and JavaScript trust boundaries, reported two sandbox failures, and documented separate vendor fixes within eight days.
accomplish.ai
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
In an isolated test workspace with no real credentials, compare each agent tool’s allowed reads and writes with the documented sandbox policy. Use inert marker files, record blocked controls, check privileged helpers separately, and stop if a host boundary is crossed. Summarize findings without creating persistence or accessing private data.
Reach people exploring AI agents
See placements →What happened
Two controlled Codex sandbox failures were reported and, according to the researcher, fixed within eight days; the account distinguishes CLI patch permissions from Desktop JavaScript trust.
Reported by Oren Yomtov — Accomplish blogHow the agent did it
- Yomtov compared blocked shell access with controlled editing-tool behavior outside the permitted workspace.
- He tested the JavaScript tool’s shared-memory trust boundary and observed an unsandboxed application launch.
- Both findings were reported to OpenAI, and the published account records remediation within eight days.
Where a person stepped in
The researcher prepared controlled proofs, compared positive and negative behavior, and disclosed findings to the vendor; readers should use isolated test data and updated builds.
Oren Yomtov tested two Codex security boundaries and reported both failures to OpenAI. This was controlled vulnerability research, with actual tool execution, rather than a report of an ordinary production compromise.
The CLI experiment compared a blocked shell write outside the workspace with an editing-tool write that succeeded. Patch permissions were derived from attacker-controlled paths, allowing a deliberately constructed patch to widen the filesystem grant. Removing the permission-widening component caused the write to be refused.
The Desktop experiment targeted the JavaScript tool’s trust separation. Trusted and untrusted contexts shared a V8 heap, exposing the secret used to authorize requests to an unsandboxed native parent. The proof of concept launched an application outside the sandbox even in read-only mode, without an approval prompt.
The researcher reported both issues on August 12 and says both were fixed within eight days. The account identifies separate updates for the CLI and Desktop. Its useful checkpoint is testing each privileged helper against the stated boundary, including components outside the model’s visible shell path. These results concern the vulnerable builds tested; they do not establish that every later Codex installation remains exposed.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: Accomplish blog · Oren Yomtov
Frequently asked questions
Were these ordinary production compromises?
No. The account describes controlled security proofs against vulnerable builds.
What differed between the two failures?
One widened patch permissions; the other exposed a secret shared across JavaScript trust contexts.
What remediation was reported?
The researcher reports fixes within eight days and identifies separate CLI and Desktop updates.
More details
About this account
Yomtov compared blocked shell access with controlled editing-tool behavior outside the permitted workspace. He tested the JavaScript tool’s shared-memory trust boundary and observed an unsandboxed application launch.
Firsthand controlled evaluation opened. Both issues share one source and are merged into one case. Fix timing is researcher-reported. This entry omits operational exploit payloads and does not claim a production compromise. Suggested prompt written by Agents In Use; no original task prompt was found in the verified text.
Credit: Oren Yomtov — Accomplish blog
Source published 15 Sept 2026
Source checked 14 Oct 2026
Tools and topics
Codex · apply_patch · node_repl · V8
sandbox evaluation · permission boundaries · disclosed remediation
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.