Codex 0.139 Alpha 2 Turns Sandbox Policy Into Something You Can Debug

Codex 0.139.0-alpha.2 looks, at first glance, like another fast-moving prerelease in a repository that already ships faster than most teams can read the changelog. That is the wrong read. The interesting part of this alpha is not the version number; it is the shape of the work: OpenAI is turning sandbox policy from a hidden runtime assumption into something operators can inspect, enforce, and debug.

That matters because coding agents are no longer glorified autocomplete. They run commands, touch files, call tools, discover plugins, hand work to subagents, and increasingly operate through app-server or cloud surfaces. In that world, “the sandbox is configured correctly” is not a reassuring sentence. It is a hypothesis you need the runtime to prove.

The official GitHub release for Codex 0.139.0-alpha.2 landed on June 9 at 04:13 UTC, only hours after the stable 0.138.0 release and the first 0.139.0-alpha.1 prerelease. The release itself is marked prerelease and shipped with 149 assets. The compare from rust-v0.138.0 to rust-v0.139.0-alpha.2 shows 45 commits, 263 files changed, roughly 7,481 additions, and 2,624 deletions. That is not a cosmetic patch. That is a runtime seam being worked on in public.

The useful feature is the one that tells you what the agent can actually do

The commit that should get platform teams’ attention is simple: Show effective sandbox modes in /debug-config. It sounds like plumbing because it is. It is also exactly the plumbing that decides whether Codex can be used responsibly beyond a solo developer laptop.

Agent policy fails in two boring, expensive ways. Sometimes the agent cannot do the thing because a project profile, managed policy, trust state, or runtime override made the environment stricter than the user realized. Sometimes the agent can do too much because the effective policy is looser than the team intended. Both show up as confusion: “why did Codex ask for approval here?” or, worse, “why did Codex have network access there?” A debug surface that reports the applied sandbox posture is the difference between policy as documentation and policy as an observable system.

This is especially important because OpenAI’s Codex security docs already describe a layered model: network access is off by default, local Codex uses OS-enforced sandboxing, and network proxy behavior constrains outbound traffic only when command network access is already enabled. That last clause is where misconfiguration lives. A proxy setting does not grant network access; it limits it once access exists. Developers will get that wrong. Enterprises will get that wrong at scale. The runtime needs to make the effective result visible, not leave everyone spelunking through TOML and assumptions.

Network proxy enforcement is not a checkbox if the sandbox ignores it

The other commit worth underlining is Enforce configured network proxy in codex sandbox. This is the kind of line item that does not trend on Hacker News and absolutely belongs in a production readiness review. If a team says “agent commands may reach the network only through this proxy,” the sandbox has to enforce that path consistently. Otherwise the proxy is a policy-shaped decoration.

There is a larger lesson here for every team adopting coding agents: controls should be tested where the agent actually executes, not where the admin UI stores configuration. Network allowlists, proxy routing, filesystem roots, plugin marketplaces, MCP server access, and approval rules all need runtime verification. A clean settings page is not evidence. A failed outbound request to a blocked destination is evidence. A /debug-config readout that matches the policy you expected is evidence. Codex 0.139 is moving toward that evidence layer.

The new -P sandbox permissions profile alias points in the same direction. It is small, but small matters in policy UX. If a safer profile is painful to invoke, developers will bypass it under deadline pressure. Teams should be defining named profiles for common modes: read-only review, workspace-write implementation, network-restricted dependency work, privileged maintenance, and perhaps a quarantined profile for unknown repositories. Those profiles need to be easy to select from CLI, TUI, app, and automation. The alias is not a keynote feature. It is the kind of affordance that makes safer behavior survive contact with a sprint.

Multi-agent scheduling is governance, not orchestration theater

The release also includes multi-agent runtime work: v2 agent residency LRU, concurrency counted by active execution, a rename from close_agent to interrupt_agent, and changes to avoid reopening v2 descendants on resume. Those are scheduling primitives, but they have direct cost and safety consequences.

A pile of dormant subagents is not the same as a pool of active workers. Counting active execution can make concurrency limits map to real resource use rather than session count theater. Avoiding stale descendants on resume reduces surprise work after a user reopens a thread. Renaming close to interrupt is more than naming polish: interrupting an agent implies stopping execution without pretending its state never existed. As agent workflows grow longer and more parallel, lifecycle semantics become part of the trust boundary.

Practitioners should translate this into tests. If you use Codex for delegated work, verify what happens when a parent session resumes, when a subagent is interrupted, when concurrency limits are reached, and when a long-running child is idle but still resident. Token budgets are not only a pricing-table problem. They are a scheduler problem.

Plugin marketplace metadata is another quiet but important surface. The release exposes marketplace source in marketplace-list JSON, uses cached remote plugin catalogs for plugin listing, prunes stale curated plugin caches, and sends the Codex product SKU to plugin-service. Once plugins can bundle skills, MCP server configuration, hooks, and app integrations, provenance becomes an audit requirement. “Which marketplace did this plugin come from?” should be machine-readable. Without that, plugin governance becomes screenshots, Slack folklore, and incident reports written in the passive voice.

There are still sharp edges. This is an alpha, the release body is sparse, and the compare touches a lot of runtime surface. Teams should not roll it out fleet-wide because the version number is newer. They should test it like an infrastructure change: does /debug-config report the sandbox modes you expect; does the network proxy block disallowed traffic; do permission profiles select cleanly with -P; do plugin inventories include marketplace source; do multi-agent sessions resume and interrupt correctly; and do cloud requirements survive thread resets?

The right editorial read is that Codex is maturing in the least glamorous, most useful direction. Better models get attention. Better sandbox visibility gets adoption. If OpenAI wants Codex to be trusted as team infrastructure, this is the work that matters: policy that is enforceable, observable, and boring enough to automate.

Sources: GitHub release — openai/codex 0.139.0-alpha.2, GitHub compare — rust-v0.138.0...rust-v0.139.0-alpha.2, OpenAI Developers — Codex changelog, OpenAI Developers — Agent approvals & security, OpenAI Developers — Plugins in Codex