Your AI Coding Agent's Sandbox Is Theater — And OpenAI's New Security Tool Doesn't Fix It

This week OpenAI quietly pushed codex-security to GitHub. No launch post, no fanfare. Hacker News found it before OpenAI could tweet about it, and by the time they did, the thread already had 491 points and 163 comments picking it apart.

The pitch is simple: a CLI and TypeScript SDK that finds, validates, and fixes vulnerabilities in your code.

npm install -g @openai/codex-security
codex-security login
codex-security scan .

Three stages: identify (walk the repo, find realistic attack paths), validate (actually try to reproduce the bug instead of pattern-matching regexes), remediate (generate a patch you can review). You can also drop it straight into CI:

const security = new CodexSecurity();
const result = await security.run(".");

Fine tool. Not the story.

The actual story is that in the same news cycle, security researchers broke the sandboxes on Cursor, Codex, Gemini CLI, and Google Antigravity — the four AI coding agents most of your team is probably running right now — and they didn't do it by attacking the sandbox. They walked around it.

The trick: the sandbox was never the trust boundary

Pillar Security's team (Eilon Cohen, Dan Lisichkin, Ariel Fogel) put it in one sentence that should be tattooed on every agent-tooling roadmap:

"The agent stays sandboxed, but the files it writes are trusted by tools outside the box."

That's the whole vulnerability class. Everyone built a nice locked room for the agent to run in, and then wired up a dozen other tools — git hooks, Python extensions, filesystem watchers, Docker — that read whatever the agent leaves on disk and execute it outside the room, no questions asked.

Cursor alone had three separate versions of this:

• CVE-2026-48124 — workspace-controlled .claude hook configs let an agent register a hook that runs unsandboxed. Fixed in 3.0.0.
• Editable virtualenv interpreters that Cursor's Python extension happily executed during environment discovery.
• Git metadata manipulation via fsmonitor that bypassed Cursor's path-based write rules.

Codex CLI's version: its "safe command" allowlist trusted git show by name, without checking what parameters were actually passed to it. High-severity bounty, CVE pending.

And Docker socket access was a shared failure across Codex, Cursor, and Gemini CLI — any of the three could reach a privileged local daemon and pivot straight to the host.

DuneSlide: zero-click, CVSS 9.8, no user in the loop

The headline pair, dubbed DuneSlide (CVE-2026-50548 and CVE-2026-50549), is the one to actually understand, because it's not a Cursor bug — it's an architecture bug that every MCP-connected agent should assume it has too.

Both score 9.8/10 on CVSS 3.1 (9.3 on 4.0), and both are triggerable with zero clicks: the payload rides in through MCP tool output or web search results the agent reads mid-task. No approval dialog, no user in the loop.

CVE-2026-50548 targets the working_directory parameter on Cursor's run_terminal_cmd tool. The sandbox's rule was "you can write to a command's working folder." Nobody validated that the working folder was the default one — so an injected instruction just sets working_directory somewhere else, and Cursor "adds that path to the allowed-write list without question." From there the attacker overwrites the sandbox helper binary itself (.../helpers/cursorsandbox), which is the thing supposedly enforcing the sandbox.

CVE-2026-50549 is a symlink resolution fallback nobody thought adversarially about: Cursor tries to resolve a shortcut to its real target, and if that resolution fails — target missing, or the attacker strips read access from a folder in the path — Cursor shrugs and trusts the symlink's apparent in-project location instead. Plant the symlink, break the resolution on purpose, get a write straight to the sandbox helper.

Cato AI Labs reported both on February 19. Cursor rejected them. They got re-triaged after escalation a week later. CVEs weren't assigned until June 5. Patched in 3.0, shipped April 2 — so there was a window where the fix existed before the CVE did.

Antigravity had its own pair (Seatbelt denylist bypass, .vscode task-config bypassing Secure Mode) — and Google's response was to downgrade both to "other valid security vulnerabilities," on the grounds that exploitation needs social engineering or trusting a malicious repo. Which is exactly the threat model for a coding agent. That's not a mitigating factor, that's the entire attack surface. If your severity rubric assumes nobody ever opens an untrusted repo in their AI coding agent, throw out the rubric.

Why the scanner doesn't touch this

Here's the part that should bother you about OpenAI's timing. codex-security scans your code for vulnerabilities you might ship. DuneSlide and its siblings aren't bugs in your code — they're bugs in the agent's runtime, triggered by content the agent merely reads: an MCP response, a search result, a README, a planted symlink. There's no diff to scan. Nothing gets committed. The exploit executes and is gone before your CI job would ever see it.

Static/dynamic scanning of the artifacts your agent produces and securing the agent's execution environment are two completely different problems, and right now the industry is loudly solving the first one while the second one is on fire.

What to actually do about it, today

Not "wait for the vendor patch." Do this now:

1. Pin agent versions and read the changelog before bumping. Cursor 3.0 closed three of these. If you're not on it, you're not protected — patch lag is the vulnerability.
2. Never point an agent at an untrusted repo with default settings. READMEs, issues, and dependency manifests are attacker-controlled text the agent will read as instructions. Treat "clone and let the agent explore" as running arbitrary code.
3. Audit what your MCP tools can actually reach. If a tool call result can steer a working_directory param or a symlink target, assume it will be weaponized. Least-privilege the tool surface, not just the sandbox.
4. Kill the Docker socket mount. If your agent's sandbox has access to /var/run/docker.sock, you don't have a sandbox — you have a container with a rootkit built in, waiting for someone to ask nicely.
5. Stop trusting "the agent is sandboxed" as a full answer in your own threat model. Ask the follow-up question every one of these CVEs is built on: what non-sandboxed process reads what this sandbox writes? Hooks, extensions, fsmonitor, git — that's your real perimeter.

Scanning code is easy to demo and easy to sell. Securing the boundary between "sandboxed agent" and "everything that trusts its output" is the actual job, and nobody's shipped that in a npx command yet.

---

Sources: OpenAI's codex-security on GitHub and the HN discussion; BleepingComputer on the Cursor/Codex/Gemini CLI/Antigravity sandbox escapes; The Hacker News on the DuneSlide CVEs.