Running Codex in a Locked-Down Container

Running Codex inside a container with its own restrictive network and filesystem policy is a layered-defense approach worth understanding on its own terms — the container provides one boundary, Codex's own sandbox provides another, and knowing how the two actually interact is what lets you configure both correctly rather than assuming one covers for gaps in the other.

Why layer a container boundary on top of Codex's own sandbox

Codex's own sandbox modes constrain what a session can do within whatever environment it's running in; they don't constrain what that environment itself can reach beyond Codex's own actions specifically. A container adds an independent layer of isolation — restricting network egress, limiting filesystem access to only what's explicitly mounted, capping available resources — that applies regardless of what Codex's own sandbox permits, which is genuinely useful for anyone wanting isolation that doesn't depend entirely on Codex's own mechanisms behaving correctly.

What a locked-down container typically restricts beyond Codex's own defaults

A genuinely locked-down container configuration commonly denies network access by default at the container level itself — a stricter, more absolute restriction than Codex's own workspace-write network default, which can still be explicitly enabled within Codex's own configuration. At the container level, denying network access means no amount of Codex-level configuration can re-enable it, since the restriction exists outside Codex's own control entirely.

Why this matters for running untrusted or unfamiliar code

A locked-down container is a particularly good fit for any task involving genuinely unfamiliar or untrusted code — reviewing a downloaded repository from an unknown source, experimenting with a package you haven't vetted — where you want isolation that doesn't rely entirely on trusting Codex's own sandbox to behave exactly as documented. Defense in depth matters more, not less, for exactly the tasks where trust is lowest.

Configuring Codex's own sandbox mode inside a locked-down container

It's worth deciding Codex's own sandbox mode deliberately even inside an already-restrictive container, rather than assuming the container's restrictions make Codex's own settings unimportant — a container with a permissive filesystem mount paired with Codex running under danger-full-access inside it still grants meaningfully more access than the same container paired with a properly scoped workspace-write. The two layers are complementary, not substitutes for each other.

What gets lost by locking things down this tightly

A genuinely locked-down container can block legitimate functionality a task actually needs — package installation requiring network access, a tool that needs to reach an external service as part of its normal, intended operation. Understanding this tradeoff explicitly, and deciding case by case whether a specific restriction is worth the friction it introduces, is more useful than either accepting every restriction uncritically or loosening the container broadly the first time something gets blocked.

Testing what actually works before relying on a locked-down setup for real work

Before committing to a locked-down container configuration for genuinely important work, running a handful of representative tasks through it and confirming they succeed as expected — not just confirming the restrictions are active, but confirming legitimate work still functions correctly under them — catches an overly restrictive configuration before it becomes a source of ongoing friction discovered piecemeal during real, time-sensitive tasks.

Balancing isolation against genuine productivity

The tightest possible lockdown isn't automatically the right choice for every task — for routine, trusted, everyday work, a heavily restricted container adds friction without a correspondingly meaningful safety benefit, since the tasks it's protecting against generally aren't present in that context to begin with. Reserving genuinely locked-down configurations for the specific situations that actually warrant them — unfamiliar code, higher-risk experimentation, genuinely untrusted input — while using a more standard setup for routine work keeps the tradeoff calibrated to actual risk rather than applied uniformly regardless of it.

The mental model worth taking away

A locked-down container and Codex's own sandbox are two independent, complementary layers of restriction, not one mechanism duplicated — configuring both deliberately, understanding what each one actually restricts, and matching the combination to the task's genuine risk level is what makes this a meaningfully safer setup rather than restrictive theater that adds friction without adding real, corresponding protection.

A concrete example of the two layers working together

Picture reviewing an unfamiliar, downloaded repository of uncertain provenance. A locked-down container with no network egress and a filesystem mount limited to just that one repository's directory provides the outer layer — even a maximally permissive Codex session inside it structurally cannot exfiltrate data or reach anything outside that single mounted directory. Codex's own sandbox, set conservatively to read-only within that container, provides the inner layer, meaning the session can't even modify the repository's own files without a further deliberate decision. Neither layer alone would be as reassuring as the two together.

Documenting a locked-down configuration for reuse

If you've built a container configuration that works well for a specific category of higher-risk task — reviewing unfamiliar code, say — it's worth saving and documenting that configuration for reuse, rather than reconstructing it from memory each time a similar situation comes up. A well-tested, reusable locked-down profile removes the temptation to skip proper isolation the next time simply because setting everything up correctly from scratch feels like too much friction in the moment, under time pressure, when the safer option would otherwise have been the obvious one to reach for.

Reviewing a locked-down profile's own configuration periodically

A container configuration built for a specific kind of higher-risk task, once written and saved, is easy to treat as permanently correct and never revisit — worth checking occasionally that it still reflects genuinely current thinking about what that category of task actually requires, rather than an early, possibly overcautious or undercautious first attempt that's simply never been reconsidered since it was originally set up.