cbox

Run Codex unattended inside a hardened container that treats the agent as untrusted - prompt injection can't escape. A shared project brain resumes work across sessions, limits, and machines.

Comment

Inspiration

I use OpenAI Codex MCP-server heavily, and I was tired of clicking "allow" on every action. I wanted Codex to run fully unattended on real work - but only inside an environment where even a hijacked agent (prompt injection, a poisoned repo, hostile tooling) could not do damage. The core idea became simple: stop approving every step, and trust the boundary instead of the agent.

It grew from there. I kept losing context every time a Codex session ended, so I gave each project a shared on-disk brain that any engine reads on startup and continues from - no re-briefing, even after a usage limit or a machine switch. What began as a safe way to leave Codex running became the console I now run Codex from every day.

What it does

cbox runs OpenAI Codex unattended inside a hardened Docker container, where the container is the security boundary:

  • Policies and rules are mounted read-only, so a prompt-injected agent cannot rewrite its own constraints.
  • SSH private keys never enter the container - only a signing socket is forwarded.
  • User-local and package directories are read-only; every delegated call is depth-limited, Git-scoped, and audited byte-for-byte.

Codex is not just launched by cbox - it is wired into it through codex mcp-server. Codex is the engine the console drives for real tasks, on GPT-5.6, and delegation runs both ways: the session hands work to Codex over MCP, and Codex can hand a question back the same way. You can also run the Codex CLI directly inside the container when you want pure GPT-5.6 with no orchestration layer. cbox was built for Codex first, and Codex is what runs it day to day.

Each project keeps a shared on-disk brain - a running LEDGER.md and PROGRESS.md - that any engine resumes from without a fresh briefing. An optional domain-allowlist egress proxy can lock all traffic to permitted domains, and routine work can be routed to cheaper tiers.

How we built it

cbox was built the way it is meant to be used: by driving OpenAI Codex. Almost all of the implementation, review, and debugging was delegated to Codex through its codex mcp-server, on GPT-5.6 exposed as four delegate tiers the console picks from per task - a fast tier for routine edits, mid tiers for complex changes, and a top tier at maximum reasoning for architecture and hard problems - each pinned to its model and effort on every call. Building the tool through the exact MCP path it exposes is why Codex is a first-class engine in it, not an afterthought.

The design is layered containment, not a growing list of prompts: Docker isolates execution, read-only mounts protect rules and sensitive state, socket forwarding keeps key material outside the container, and Git-scoped auditing constrains delegated work. Continuity is deliberately file-based - plain Markdown on disk, engine-agnostic, so it survives anything that kills a session.

Challenges we ran into

The hardest problem was preserving usefulness while treating the agent as potentially compromised. An unattended agent needs broad power, but prompt injection can arrive through source files, dependencies, command output, or a delegated task - so every convenience had to be examined as a possible path around the boundary.

Wiring Codex in through codex mcp-server had its own sharp edges: enforcing a specific model and effort per task, injecting the rules Codex must follow, and bounding delegation depth so one agent could not escalate through another. Reaching real infrastructure from inside the sandbox is harder still - it can collapse isolation if the routing controls are incomplete, which is why that part is built carefully and gated behind a live host check.

Accomplishments that we're proud of

  • Unattended autonomy that is safe by construction: Codex runs with no approval prompts, yet a compromised agent stays contained - read-only rules, isolated keys, scoped mounts, audited delegation.
  • cbox proved itself by building itself. The whole tool was produced by driving Codex through the same MCP path it ships - so "Codex as a first-class engine" is not marketing, it is how the codebase got written.
  • Continuity that actually holds: a pile of disconnected sessions became one long-running collaborator that picks up mid-task after a limit or a reboot, with zero re-explanation.

What we learned

Autonomy is far easier to accept when trust moves from the model to an enforceable boundary. Instructions matter, but controls the agent cannot modify matter more. The safest secret is one that never enters the environment; the safest network capability is one that is explicit, narrow, and optional.

I also learned that a coding agent feels capable through continuity, not just intelligence. A small set of disciplined, human-readable files preserved decisions and unfinished work more reliably than any provider-specific session history.

What's next for cbox

cbox is not finished - it keeps growing to fit what I actually need from it. The roadmap is concrete, not aspirational, and it is written down in the repo. The near-term work, roughly in order:

  • A vendor-neutral session hub. Bare cbox becomes a project session manager: it lists the sessions in a project, and lets you resume any of them in any engine. Exit one engine, the container stays up, and the same session continues under a different driver - Codex, or another agent - with the outgoing context distilled into a neutral handoff block and seeded into the next engine. The shared brain carries the project state; the handoff carries the conversation. The store and the distillation are built; the full hub UX and the live Claude/Codex/Hermes handoff are the next milestone.
  • Shared project sessions, end to end. .cbox/sessions/ already indexes each project's sessions and maps them to their native engine transcripts. Next is live import, native resume, and a host-side cbox ps viewer to see running containers and their sessions, and attach, stop, or recover a stuck one.
  • A third engine, Hermes, is already wired in as a console option; I have not finished testing it end to end, and it lands in the next few days because I want it for my own workflow.
  • Infrastructure access. netaccess gives a sandboxed agent a scoped SOCKS path to other Docker networks and raw CIDR ranges such as a k3s pod network. The lifecycle is implemented - it joins eligible networks, renders the proxy routes, and cleans up stale attachments - and the remaining step is live verification on a real Docker/k3s host. This is what I need most day to day.
  • A code-quality refactor. This was built fast, under a sprint, by delegating hard to Codex - which got the behavior right and the tests green, but left the codebase denser than I want to maintain. Consolidating it is deliberate next-step debt, not an afterthought: a runtime whose whole point is a trustworthy boundary has to stay auditable.
  • The larger roadmap then unifies the project scope fully under .cbox/, adds a single policy source compiled per vendor, brings the remaining Codex parity, and reaches toward a k3s/fleet profile.

All of it ships without weakening the promise that makes the whole thing work: the agent gets the access it needs for real work, while the boundary stays in control.

Notes on context

I used Codex two ways, on purpose - through the Codex CLI directly when I want pure GPT-5.6 with no other engine in the loop, and through its MCP server (codex mcp-server) on GPT-5.6 orchestrated from my own console when I want Codex driven as part of a larger workflow. I built cbox with both. Because most tasks ran as isolated delegations, the work is spread across many Codex sessions rather than one long thread - the largest single Codex session on this project is 019f772b-a8fd-7fa2-95f8-e0c328442b1b.

Timeline: the idea started as a private sketch on 2026-07-12; the public repository began with a working prototype on 2026-07-15, inside the submission window. I only came across the competition mid-week and decided to enter then. Since then cbox has been my daily driver for real project work - and I develop cbox inside cbox, which is exactly how the steady stream of patches came about.

Built With

Share this project:

Updates