Sanbox Gives AI Agents MicroVM Sandboxes

Sanbox, batteries included sandboxes for AI agents, is a project from the Sanbox.cloud maintainers for running coding agents in isolated, resumable environments. It deals with a problem every agent-heavy repo eventually hits: the model can edit files, run commands, and touch tools faster than you can reconstruct what happened. The practical takeaway is simple: a good Codex review is not just a prompt, it is a contained run with repo rules, a diff, logs, and verification commands. For Codex users asking how to use codex code review, Sanbox points to the missing layer around the review: the room the agent runs in.

Sanbox is a hosted or self-hostable sandbox platform that gives each agent run MicroVM isolation, a persistent filesystem, and a live trail of run events. As of July 2026, its public pitch is deliberately broad: the CLI can work with Codex, OpenAI's coding agent, Claude Code, Anthropic's coding agent, Codex, Anysphere's AI code editor, CI, or a plain terminal.

Watch the room, not just the agent

An agent sandbox is an isolated runtime where an AI agent can inspect a repo, change files, run commands, and leave behind evidence without sharing the same blast radius as your laptop or production CI.

That is why Sanbox got attention on Hacker News. The interesting part is not that it can launch an agent. The interesting part is that it treats agent work like a resumable computing session instead of a chat transcript with side effects.

Sanbox says it uses the OpenCode SDK as the harness, supports reusable templates, keeps filesystem state, and records a live trail of events. That combination matters when a coding agent says, “I fixed it.” You want to see what it read, what it changed, what it ran, and where it stopped.

The trap is thinking prompt discipline replaces containment. A careful prompt can reduce mistakes, but it does not isolate shell commands, dependencies, generated files, or tool calls.

Make Codex review a contained experiment

The clean Codex workflow is to put the repo, the diff, and the verification loop inside the same sandbox. That keeps the review close to the actual code while making the run easier to inspect later.

For a Codex CLI review code changes flow, avoid treating “review this” as a magic command. Give Codex a bounded job: inspect the current diff, compare it to repo rules, run the smallest useful tests, and return findings with file paths.

A simple local shape looks like this once your sandbox has the repo checked out:

git status --short
git diff --stat
git diff -- src tests

codex "Review the current git diff for correctness, security, missing tests, and risky behavior. Use AGENTS.md as the repo contract. Do not edit files unless asked. Return findings with file paths and verification commands."

npm test -- --runInBand

The same idea fits a Sanbox run: start from a reusable template, mount or clone the repo, let Codex inspect the diff, and keep the sandbox event trail as the review receipt. If the review finds a risky migration, a flaky test, or a missing permission check, you have the file state and command history needed to replay it.

This is the practical part of how to use codex code review well: the review should produce evidence, not just advice. The trap is letting the agent both author and approve the same change without a separate verification step.

For more Codex CLI workflow patterns, keep the related training topic nearby rather than scattering one-off prompts across repos.

Put repo rules where the sandbox can see them

Codex gets much better at review when the repo contract is written down. OpenAI's AGENTS.md convention is a natural fit because the file can travel with the repo into the sandbox.

Here is a small review-oriented AGENTS.md fragment for a Node service:

# AGENTS.md

## Review contract
- Treat generated files and lockfiles as reviewable changes.
- For API handlers, check auth, input validation, and error shape.
- For database changes, look for backward compatibility and rollback notes.
- Before marking a review complete, run: npm test -- --runInBand
- Return review findings as: severity, file path, line or function, reason, suggested fix.

## Tool boundary
- Do not call external write APIs during review.
- Read-only docs and issue links are allowed.
- Ask before changing source files.

That file is boring in the best way. It gives Codex review criteria before the model starts improvising.

If your review uses MCP to reach GitHub, Slack, Jira, docs, or a private knowledge base, write down the boundary too. MCP is powerful because it connects the agent to real systems; it is risky for the same reason. We covered a related policy-boundary story in Kastra Enforces Policies for Claude Code, Codex, and Codex, and Sanbox sits in the same neighborhood from the runtime side.

The trap is hiding review rules in a human checklist that never reaches the agent. If the sandbox has the repo but not the rules, the model will invent a local standard.

Know when Sanbox is too much

Sanbox is a good fit when the agent needs to run real commands, keep state between attempts, or produce a trail someone else can inspect. It is especially interesting for Codex code review on larger diffs, dependency upgrades, generated code, migrations, and flaky test investigations.

It may be overkill for a two-line copy change, a one-off local refactor, or a repo where the agent is only reading code. A plain Codex CLI session can be enough when the blast radius is low and the commands are cheap to rerun.

There are also product edges to watch. The Sanbox maintainers describe network ACLs, secrets management, LLM cost tracking, and observability as roadmap items as of July 2026. That is a useful signal: treat sensitive network access and secret handling as design questions, not assumptions.

A good rule of thumb: use a sandbox when the review needs a receipt. Skip it when the review is only a quick read.

Copy this try-it-safely checklist

Use this checklist for a first Sanbox-style Codex review. It is intentionally small. You are trying to learn whether the sandbox improves evidence, not proving a whole platform in one afternoon.

• Pick a non-sensitive repo or a scrubbed branch.
• Choose a real diff: dependency bump, API handler change, migration, or failing test fix.
• Add or tighten AGENTS.md with review rules and verification commands.
• Start from a reusable sandbox template with the same runtime your CI uses.
• Run git status --short and git diff --stat before calling Codex.
• Ask Codex to review only; do not let it edit on the first pass.
• Run the repo’s smallest meaningful test command inside the same environment.
• Save the review output, command log, and final diff as the receipt.
• Check whether the sandbox made the review easier to trust or merely slower.
• Do not add secrets, write-capable MCP tools, or production network access on the first run.

The success case is modest: one useful finding, one reproducible test result, and one event trail you can hand to another engineer without narrating the whole session.

Common questions

• What is Sanbox for AI agents?

  Sanbox is a platform for running AI agents in isolated and resumable sandboxes. Its public description highlights MicroVM isolation, persistent filesystem state, reusable templates, a CLI, and a live trail of run events, with self-hosting available for security or compliance needs.

• How should I run a codex code review inside Sanbox?

  Run the review as a bounded diff inspection, not an open-ended coding session. Put the repo and AGENTS.md inside the sandbox, ask Codex to review the current git diff, run the smallest relevant test command, and keep the event trail as the review receipt.

• Does Sanbox replace CI?

  No, Sanbox should not replace CI. It is better viewed as a safe workroom before or beside CI, where an agent can inspect code, run commands, and preserve context while your normal CI remains the final automated check for the branch.

• Can I use codex cli review code changes without a sandbox?

  Yes, you can ask the Codex CLI to review code changes directly in a local checkout. A sandbox becomes useful when the command history, filesystem state, dependency install, or tool boundary needs to be isolated and replayable rather than trusted from a developer laptop.

• What should I be careful with first?

  Be careful with secrets, network access, and write-capable integrations. Sanbox lists network ACLs, secrets management, LLM cost tracking, and observability as roadmap work as of July 2026, so the safest first experiment is a read-only review on a branch with no production credentials.

Best ways to use this research

• Best for: Developers using Codex CLI on diffs that need command evidence, not just a natural-language review.
• Best first artifact: A short AGENTS.md review contract with test commands, severity format, and MCP boundaries.
• Best comparison angle: Compare Sanbox against a local Codex session by asking which one leaves a better receipt for the same review.
• Best caution: Treat roadmap security features as roadmap features. Start with non-sensitive repos and read-only tool access.

Further reading

• Sanbox, batteries included sandboxes for AI agents — source
• OpenAI Developers — AGENTS.md guide
• OpenAI Developers — Codex CLI

Try one boxed review

Pick one real diff, add a small AGENTS.md review contract, and run Codex in a sandboxed environment where the commands and file state are preserved. If the receipt is clearer than your usual review notes, Sanbox is worth a deeper look.

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.