Codex 0.136 Alpha Tightens the Agent Runtime Where It Can Actually Hurt You
Codex 0.136.0-alpha.2 looks, from the release page, like nothing happened. The note is a single line: “Release 0.136.0-alpha.2.” That is technically true in the same way a locked data center door is “a hinge update.” The actual diff is a useful snapshot of where coding-agent products are getting serious: not prettier chat, not another autocomplete flourish, but permissions, sockets, tokens, sandboxes, hook schemas, and the awkward edge cases where an agent runtime can quietly become an incident report.
OpenAI published the alpha on May 31 at 19:40 UTC. The compare range from rust-v0.136.0-alpha.1 to rust-v0.136.0-alpha.2 spans 58 commits, 300 files, 7,959 additions, 3,054 deletions, and 11,013 changed lines. That is not a patch-note shrug. It is a control-plane release hiding behind the least informative changelog format available to humans.
The important changes cluster around one question: when Codex is allowed to act, what exactly is it allowed to reach?
The safe command was never the security boundary
The sharpest fix is PR #23943, which preserves deny-read sandboxing even for commands treated as safe or explicitly allowed. This is the kind of bug that sounds academic until you deploy agents across real repositories. Teams often reason about command risk as if the executable is the unit of security: ls is fine, cat is probably fine, rm needs review, curl deserves suspicion. But a read-capable command is only safe relative to the paths it can read.
If a permission profile says private files, secrets, or excluded subtrees are unreadable, that constraint has to survive the fact that the command itself looks harmless. Otherwise the approval layer becomes a vocabulary trick: call the operation “safe,” and path-level denial evaporates. Attackers do not need a dramatic exploit if they can route around policy through a command the product has already decided to trust.
That is the practitioner lesson here. Do not build agent policy around command names alone. Build it around command capability, path scope, network scope, working directory, symlink behavior, and the active permission profile. Then test the combinations that feel boring: cat against a denied file, ls through a symlink, a safe command inside an untrusted repo, and a resumed session after policy has changed. Coding-agent security failures are often not one giant missing guardrail; they are two reasonable shortcuts composed into one bad outcome.
Local WebSockets need browser-hostility by default
PR #24947 rejects codex exec-server WebSocket requests that carry an Origin header, returning 403 Forbidden. That brings the local exec-server closer to the app-server browser-origin behavior and reduces the chance that a random local page, extension, or browser context can initiate an unintended connection.
This is table stakes, but table stakes are exactly what agent runtimes need more of. Local servers are seductive product surfaces. They make remote steering, mobile follow-ups, IDE/app integration, and tool execution feel native. They also create a local control plane that other processes may discover. The browser is not a friendly neighbor in this design; it is an environment full of pages you did not write and extensions you may not fully audit. Rejecting browser-originated WebSocket attempts is not paranoia. It is acknowledging that localhost stopped being private the moment developer tooling started exposing meaningful authority there.
The server-token migration in PR #24141 fits the same pattern. Codex remote control is moving away from using the user’s ChatGPT access token for server WebSocket connections and toward short-lived server tokens minted from durable enrollment identity. The token is memory-only and refreshed without persisting the bearer credential. That distinction matters. Durable enrollment can prove that a machine is allowed to participate; the active bearer secret should still be narrow, temporary, and unpleasant to steal.
For teams evaluating Codex as an engineering runtime, this should become part of the rollout checklist. Inventory local listeners. Probe them from a browser page. Confirm origin rejection. Confirm remote reconnect behavior does not persist long-lived user credentials in places support logs or crash dumps might capture. Treat localhost services as production services with a smaller audience, not as magic pipes exempt from threat modeling.
Permission context is part of enforcement
Another quiet change, PR #23924, surfaces filesystem permission profiles in model-visible context and approval-review prompts. This is easy to dismiss because enforcement should live in the sandbox, not in the model’s vibes. True — but incomplete. Agent governance has at least three layers: what the sandbox actually enforces, what the model is told it may do, and what the human or approval model can inspect when escalation happens.
If Codex only says “sandbox mode enabled” while omitting that the current profile grants workspace reads but denies private subtrees, the model may plan around the wrong mental model. Worse, an approval reviewer may see a generic safety label and miss the actual denial rules being tested. The model should not be trusted to enforce the profile, but it should be given the profile so it can avoid unnecessary escalation and produce reviewable intent.
This is where mature agent systems are heading: explicit permission profiles, active policy in prompts, enforcement below the model, and logs that make the profile visible after the fact. If your internal agent wrapper has a policy name like “developer mode” or “safe mode” without a concrete, inspectable description of filesystem, network, tool, and approval boundaries, rename it or delete it. Ambiguous safety labels are how teams comfort themselves right before they learn what the runtime actually allowed.
Windows sandbox cancellation also deserves more attention than it will get. PR #19880 closes a gap where a command whose network attempt had already been denied could keep running until timeout. Policy denial should not be advisory. If the network proxy says no, the process should stop promptly, and the event should be visible. A denied network attempt may be harmless dependency discovery, or it may be the first sign of a repo trying to phone home. Either way, letting the process limp along turns a clear policy event into mush.
The hook schema tightening in PR #24962 is in the same family. A pre-tool-use.command.output schema should not validate a mismatched hook event like PostToolUse. Hook systems are policy plumbing; loose schemas make policy look present while allowing the wrong event shape to slip through. The fix is small, but the principle is large: if tool governance depends on structured events, event identity must be precise enough to fail closed.
Codex also adds model metadata for tool behavior — direct, code_mode, and code_mode_only — while treating unknown or omitted values conservatively. That is a good default. Agent runtimes are now routing work across models with different tool affordances, and “unknown” should not mean “sure, let it drive.” Capability metadata is boring until a model is handed a tool mode it was never meant to operate.
The practical advice is not glamorous. If you run Codex in a team setting, stage this alpha instead of spraying it across every laptop. Re-run a hostile-agent test suite: denied file reads, symlink paths into denied areas, local WebSocket attempts from browser contexts, remote-control reconnects, failing hooks, denied network calls, and Windows cancellation behavior. If you do not have that suite, this release is your hint to build one. The future of coding agents will not be decided only by model benchmarks; it will be decided by whether runtimes fail closed when the task, repo, browser, shell, and human approval layer disagree.
Codex 0.136.0-alpha.2 is not exciting in the demo sense. Good. The useful work in agent tooling right now is mostly about making authority less ambiguous. Ambiguity is where agents leak secrets, overrun budgets, and make operators invent folklore. This release does not solve that whole problem, but it moves several of the seams in the right direction.
Sources: OpenAI Codex 0.136.0-alpha.2 release, GitHub compare range, PR #24947, PR #23943, PR #24141, PR #23924.