Codex and Codex Hit by Sandbox Escapes

Codex, Codex, Gemini CLI, Antigravity hit by sandbox escapes is a BleepingComputer security report about escape paths in popular AI coding tools: Codex, Anysphere’s AI code editor; OpenAI Codex; Google Gemini CLI; and Google Antigravity. The problem is simple and uncomfortable: an agent that is supposed to work inside a safe boundary may find a way to act outside it. The takeaway for a Codex CLI workflow is not “stop using agents”; it is “treat sandbox boundaries as review inputs, not magic walls.” A good codex code review now checks the diff, the commands, and the permissions the agent could touch.

A sandbox escape is a failure where code or a tool breaks out of the restricted environment meant to contain it. In AI coding, that boundary matters because the agent is not only reading files; it may run tests, call tools, edit code, and follow instructions found in the repository.

Read the report as a boundary failure, not a product ranking

The useful reading of this story is boring in the best way: several coding assistants were reported to have sandbox escape issues, and that points to a shared class of risk. Codex, Codex, Gemini CLI, and Antigravity do not have to be identical for the lesson to hold. They all sit close to source code, terminals, local files, and developer credentials.

That closeness is why developers cared. A coding agent is most helpful when it can inspect a repo, run commands, and make changes. Those are also the exact privileges that make an escape worth worrying about.

The trap is turning the report into a brand argument. The stronger question is: “What could this agent reach if the boundary fails?” In a real repo, the answer might include .env files, SSH config, package manager tokens, database dumps, or a local browser session.

For Codex users, this is where the codex cli workflow should get more explicit. OpenAI Codex can be useful for local code changes and review loops, but the safe default is to keep its job narrow, make permissions visible, and verify outputs outside the agent’s own narrative.

Follow the escape path through a normal coding task

Picture a small Node service with a failing test. You ask an agent to fix packages/billing/src/tax.ts, run the test suite, and open a diff. Nothing about that prompt sounds dangerous.

Now add the parts we forget to mention. The repo has a root AGENTS.md. The test command can execute arbitrary package scripts. The workspace contains .env.local. The developer shell has GITHUB_TOKEN and registry credentials. The agent can read error logs that may contain secrets.

That is the shape of the exposure. The risky moment is not always “the model writes bad code.” It is often “the model is allowed to run a normal-looking command in a place where normal commands have too much reach.”

This is why agent sandboxes are hard. A useful coding agent needs file access and process execution. A safe coding agent needs those same capabilities boxed in tightly enough that a malicious package script, prompt injection in a README, or unexpected tool call cannot turn a code task into a credential task.

The related pattern shows up in other sandboxed-agent stories too. We covered a similar boundary lesson in Hermes Agent Runs Kimi K3 in a Sandbox: the sandbox is part of the product experience, not an implementation detail you can ignore.

Keep Codex work inside a small repo boundary

The practical move is to make the boundary smaller than your laptop. For Codex CLI workflows, start with a clean checkout, a narrow task, and no ambient secrets. Then let Codex operate inside that workspace instead of your whole development environment.

A good AGENTS.md helps because it turns “what this agent may do here” into repo-local instruction. It should not be a novel. It should state the safe commands, the files that are off-limits, and the verification loop expected before a change is considered ready.

Here is the kind of instruction I would put in a small service repo:

# AGENTS.md

## Scope
Work only inside this repository. Do not read files outside the repo root.
Do not inspect .env*, SSH config, browser data, keychains, or cloud credential files.

## Allowed commands
- npm test -- --runInBand
- npm run lint
- npm run typecheck
- git diff --stat
- git diff

## Before finishing
Show the files changed, commands run, and any command failures.
Do not claim tests passed unless the command output is shown in the final summary.

This is not a perfect security boundary. It is a clear contract. The real enforcement still has to come from the operating system, container, permissions, and the CLI’s own safety model.

The trap is using instructions as if they were isolation. Instructions reduce accidental overreach. They do not stop a compromised dependency, a shell escape, or a tool bug from touching what the process can already reach.

Review the change without trusting the transcript

The best review posture is friendly paranoia. Let Codex help, but review the artifact that will ship: the diff, the commands, and the runtime behavior. The chat transcript is useful context, not proof.

For a codex review, ask for a concise handoff rather than a story. Good handoffs include changed files, commands run, command outputs, known failures, and open questions. Bad handoffs say “fixed the issue” and leave you to discover the blast radius later.

A tight openai codex cli review can look like this:

git status --short
git diff --stat
git diff -- packages/billing src tests
npm run lint
npm run typecheck
npm test -- --runInBand

Then read the diff with one security question in mind: did the agent expand its own authority? Watch for new shell execution, new network calls, wider file globs, dependency changes, postinstall scripts, logging of secrets, or test fixtures that quietly encode credentials.

The tradeoff is speed. A narrow permission boundary and a manual verification loop feel slower than asking the agent to “just fix it.” After a sandbox escape report, that friction is the point. You are buying a smaller failure mode.

Copy this risk check before you let an agent run

Use this as a light pre-flight before asking Codex or another coding agent to edit and execute code. It is intentionally small enough to use on a Tuesday afternoon.

A minimal MCP boundary note can live beside your repo instructions:

## MCP boundary
Use read-only tools unless this task explicitly asks for a write.
Do not create issues, comments, branches, pull requests, tickets, or database rows.
When external context is needed, summarize what was read and include the resource name.

That note will not save you from every escape. It will prevent a lot of sloppy “while I was there” behavior. It also makes codex cli review code changes easier because the reviewer can compare the requested task with the permissions actually used.

Common questions

• Does this mean Codex CLI is unsafe to use?

  No, it means Codex CLI should be used with a real boundary around files, commands, and secrets. The BleepingComputer report is about sandbox escapes across multiple AI coding tools, not a reason to abandon agent workflows. The practical number to remember is one workspace: one clean repo checkout with only the credentials the task truly needs.

• What should change in a codex code review?

  A codex code review should include permissions and command history, not only the final diff. Ask for changed files, commands run, failures, and any external tools used. The caveat is that the agent’s summary is not evidence; re-run key checks yourself and inspect risky changes like dependency updates or shell execution.

• Are AGENTS.md rules enough to stop sandbox escapes?

  No, AGENTS.md rules are instructions, not an operating-system security boundary. They are still worth writing because they reduce ambiguity and make review easier. The hard boundary comes from process isolation, least-privilege credentials, read-only tool scopes, and keeping secrets out of the working directory.

• Should MCP tools be disabled for coding agents?

  Not always, but MCP tools should start read-only and narrow. A coding task rarely needs write access to GitHub, Slack, Jira, and a database at the same time. The useful artifact is a permission table per task: resource, read/write level, reason, and what output must be included in the handoff.

• What is the easiest safe experiment after reading the report?

  Run one agent task in a clean clone with fake environment values and no external write tools. Ask for a small bug fix, then compare the agent’s handoff with git diff, test output, and shell history. If those disagree, fix the workflow before giving the agent a larger task.

Best ways to use this research

• Best for: Codex users who already let agents edit code and run tests locally, and want a sharper boundary after the Codex, Codex, Gemini CLI, and Antigravity sandbox escape report.
• Best first artifact: Add the small AGENTS.md scope block above to one repo, then require changed files and command output in every agent handoff.
• Best comparison angle: Compare tools by what the agent process can reach, not only by model quality or editor polish.
• Best practical limit: Keep secrets out of the workspace before the agent starts. It is easier than proving every tool call is harmless afterward.

Further reading

• OpenAI Developers — Codex CLI
• OpenAI Developers — Codex CLI features
• Codex, Codex, Gemini CLI, Antigravity hit by sandbox escapes — source

One next step

Before your next agent-assisted change, run it in a clean repo checkout with no real secrets and require a diff-plus-commands handoff. If that feels too heavy, use it first only for dependency changes, shell scripts, and anything that touches authentication.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.