Ask HN: What Agent Sandboxes Are Missing

By Rogier Muller07.09.26

We could not recover the original Ask HN thread from the day this was written. Treat the sandbox gaps below as the argument, not a quote from a named post.

An Ask HN thread from July 2026 asks what agent sandboxes are missing. It was started by oryx1729, 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 Adding 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.

Watch for 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.

Don't add 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.

Watch for 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 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.

Don't trust 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

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.

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.