Ask HN: What Agent Sandboxes Are Missing

Ask HN: What are agent sandboxes missing? is a July 2026 Hacker News discussion started by a builder designing an agent sandbox platform on the OpenCode SDK. An agent sandbox is an isolated work area where a coding agent can run commands, inspect files, call tools, and produce output without getting full access to the host machine. The thread asked a very practical question: what does a sandbox need beyond a container and a prompt? For OpenAI Codex, OpenAI’s coding agent, the takeaway is simple: how to add mcp to codex matters less than where that MCP door leads, what it can touch, and how the human reviews what came back.

The poster described a CLI-first platform for launching sandboxes, fetching prompts and data, reviewing generated outputs, and managing queues for questions the agent needs to ask a person. They also sketched an AI gateway layer, similar in spirit to Tailscale’s Aperture work, for watching network access, distributing secrets, and deciding what an agent may reach.

That is why the thread hit a nerve. Developers already know how to put a process in Docker. The harder part is making a Codex agent useful inside the box without turning the box into theater.

Treat the sandbox as a workbench, not a prison

The interesting part of the Ask HN thread was not whether Docker can isolate code. It can. The question was whether a sandbox can feel like a good coding workbench once an agent is inside it.

A container gives you process isolation, filesystem boundaries, and cleanup. It does not automatically give you good prompt loading, artifact review, human question queues, secret handling, or network policy. Those are the places where agent work gets messy.

Take a normal backend repo. A Codex CLI session may need to inspect the test suite, run npm test, read a migration plan, ask whether a breaking API change is acceptable, and return a patch plus a short receipt. If the sandbox only says yes or no to shell commands, the agent still has to improvise the whole workflow.

The trap is thinking the sandbox’s job is to block everything. A useful sandbox blocks the dangerous paths, then gives the agent narrow, boring paths for the work you actually want done.

For more Codex workflow examples, the related Codex CLI workflows topic is the better home than this story note.

Add one boring MCP doorway

MCP is the Model Context Protocol, a standard way for an AI client to connect to external tools and data sources through named servers. In Codex work, MCP is best treated as a doorway through the sandbox wall, not as a magic plugin bucket.

This is the practical Codex CLI MCP lesson from the thread. Start with one server that exposes one safe capability. For example, give a Codex agent read-only access to repo facts, build metadata, or internal docs before you give it write access to GitHub, Slack, Jira, or production databases.

A small codex mcp boundary beats a giant toolbelt. A repo_facts server that can answer “what services depend on this package?” is safer than a general filesystem server with broad paths mounted into the sandbox.

The trap is adding MCP because the agent feels underpowered. If the sandbox is missing context, fix the context path. Do not quietly give the agent credentials, browser reach, and write APIs just to make one task pass.

Do not confuse web access with useful research

One objection in the thread was very real: some platforms block traffic from known AI or sandbox IP ranges. That makes web fetch tools unreliable for research, even when the user has a legitimate reason to collect public information.

This is where a gateway layer becomes more than security furniture. It can decide which hosts are allowed, route through approved egress, record what was fetched, and keep secrets out of the agent’s shell environment. It can also say no before the agent burns time retrying a blocked request.

For Codex users, the practical move is to separate “the agent may use the internet” from “the agent may use these approved network paths.” In an issue triage workflow, let the agent fetch your own docs, package registries, and CI logs. Do not assume it can scrape Reddit, private forums, or arbitrary search results from a sandbox IP.

The trap is pretending that blocked web access is only a UX problem. It is also a provenance problem. If the agent cannot fetch the page reliably, your review receipt should say that plainly instead of smuggling in a guessed summary.

If you are comparing local agent surfaces, Rowboat vs Claude Desktop: Local Work Surfaces is a useful adjacent read.

Review the output without replaying the chat

The poster’s mention of generated-output review and ask-user queues is easy to skip. It may be the most important part.

A sandboxed agent still needs a handoff shape. The human should not have to replay a long chat to learn what changed, what failed, what question blocked progress, and what commands ran. Claude Code, Anthropic’s coding agent, and Codex both work better when the repo tells the agent what a good receipt looks like.

Put that instruction close to the code. In a service repo, an AGENTS.md file can tell Codex to end every change with test results, touched files, unresolved questions, and any network or MCP access used. That is not ceremony. It is how you make sandbox output reviewable.

The trap is trusting isolation so much that you stop asking for evidence. A contained wrong patch is still a wrong patch.

Try it safely: one MCP server, one receipt

Here is a small experiment that fits the spirit of the Ask HN thread. It gives the agent a narrow MCP capability and a review receipt, without turning the sandbox into a general-purpose automation bot.

Use it for a local Codex CLI MCP test against a non-sensitive repo. Adjust paths and commands to match the current Codex CLI docs before you keep it.

# ~/.codex/config.toml
# Keep the sandbox narrow while you test the integration.
sandbox_mode = "workspace-write"

[mcp_servers.repo_facts]
command = "node"
args = ["./tools/mcp/repo-facts-readonly.mjs"]
env = { }

Add a local repo rule next to the code:

# AGENTS.md

When working in this repo:

- Use the repo_facts MCP server only for read-only repository context.
- Do not request secrets, tokens, customer data, or production credentials.
- Before editing files, state which files you expect to touch and why.
- After the change, report: files changed, commands run, test results, MCP tools used, and open questions.
- If a network request fails or appears blocked, say so directly instead of guessing the page contents.

Then run a tiny task:

codex "Find the smallest failing test related to the billing date parser, propose a fix, and stop before editing if repo_facts shows another service depends on that parser."

That is the whole test. You are not proving that agent sandboxes are solved. You are checking whether the sandbox can support context, restraint, and review in one ordinary coding loop.

Common questions

• How do I add mcp to codex without weakening the sandbox?

  Add one MCP server with one narrow purpose, then write an AGENTS.md rule that says when Codex may use it and what must be reported afterward. The useful starting point is read-only repo context, not write access to external systems. Treat every new MCP server as a new permission boundary.

• Where should a codex cli mcp server run?

  Run the first Codex CLI MCP server locally or inside the same controlled sandbox as the coding task, unless it needs a managed network path. The important detail is not location alone; it is whether the server can reach secrets, private APIs, or broad filesystem paths. Keep the first server boring and inspectable.

• Is Docker enough for agent sandboxes?

  Docker is enough for many isolation basics, but it is not enough for the whole agent workflow. The Ask HN thread pointed at missing pieces around mounted directories, cleanup, gateways, prompt retrieval, output review, and human question queues. Containers answer “where does it run?” They do not answer “what should it be allowed to know?”

• Why do sandboxed agents struggle with web fetch?

  Some websites block traffic from AI-related or cloud sandbox IP ranges, so web fetch can fail even when the task is reasonable. The fix is not to hide the agent. The safer pattern is approved egress, clear fetch logs, and receipts that say when a page could not be retrieved.

• Should MCP tools be available to every Codex task?

  No. MCP tools should match the task’s risk and context needs. A documentation lookup server may be fine for most tasks, while a database, issue tracker, or deploy tool should require a narrower prompt and a stronger review receipt. The safest default is fewer tools with clearer names.

Best ways to use this research

• Best for: Codex users deciding whether their agent sandbox needs more than shell isolation. The useful question is not “container or no container?” It is “what controlled paths does the agent need to do real work?”
• Best first artifact: A small AGENTS.md receipt rule plus one read-only Codex MCP server. This gives you a real signal without adding a broad integration surface.
• Best comparison angle: Compare Docker-style isolation with agent-native workflow needs: prompt loading, MCP access, network egress, ask-user queues, and output review.
• Best warning sign: The agent needs broad secrets or arbitrary web access to complete a simple code task. That usually means the sandbox boundary is compensating for missing context design.

Further reading

• OpenAI Developers — AGENTS.md guide
• Model Context Protocol — specification
• OpenAI Developers — Codex CLI

Keep the wall, add a door

The Ask HN thread is a good reminder that agent sandboxes are not just smaller VMs. Start with one narrow MCP doorway and one review receipt, then see whether Codex can do useful work without pretending the wall is gone.

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.