Codex MXC Sandbox: Network Realities and Silent Fallbacks

Ethan Park

Thanks to Jellypod for helping make this daily show a reality. Last time we were on Windows, we dug into the sharing violation bug that broke sandbox startup. Today is the next problem you hit once the sandbox does start. If you're evaluating the newer MXC backend on Codex 0.162.1, there's a counterintuitive point: picking MXC does not restrict your network by itself.

Maya

That one matters because the name sounds like a promise. You choose a sandbox, so you assume the box is closed. What does the source say actually happens?

Ethan Park

The source is a review from Superpower Daily, published October 9, 2026. They traced the release tagged source for stable 0.162.1, and compared selection controls against the 0.163.0 alpha 4 prerelease. Important qualifier up front: this was a source review. They did not run Codex, they did not test packets, and they did not confirm the tagged source matches the shipped binaries. So this is about generated configuration, not a demonstrated escape. Within that scope, the finding is clean. The policy translator takes your permission profile and decides the network rules. The backend name is not what sets them. Two inputs matter: is networking enabled in the profile, and is there a managed network context.

Maya

So walk through the cases, because I think people will want to map them to their own setups.

Ethan Park

Case one: a network disabled profile, say read only, with no managed networking. MXC generates deny defaults for egress, ingress, and host loopback. Host loopback means traffic back to the same machine. That's the closed box people imagine. Case two: a network enabled profile without managed networking. Now MXC generates allow defaults for all three. Outbound is open, inbound is open, and localhost is open. You're running in the MXC sandbox, and the network is wide open.

Maya

And to be fair, that doesn't mean MXC does nothing. Filesystem permissions are translated separately, right?

Ethan Park

Right. Writable paths, read only paths, denied paths, including read only carveouts. The request also disables mutation of discretionary access control lists. So the review is very specific: network allow defaults describe one dimension of the generated policy. They are not unrestricted execution. Also, other operating system or organizational controls could still restrict access even when MXC generates allow defaults. The review just can't speak to those.

Maya

What about the third case, managed networking? I'd guess that's the one teams reach for when they want a proxy in the middle.

Ethan Park

It is, and it has a subtle edge. With managed networking, non loopback traffic is denied by default. Good. But loopback is permitted across all ports, both IPv4 127.0.0.0/8 and IPv6 ::1. Setup validation does require an executor local proxy context, dedicated nonzero proxy ports, and allow_local_binding set to true. You'd read that and think the loopback allowance is confined to those proxy ports. It isn't. The generated native filter does not restrict loopback to them. Those ports are a setup requirement, not the boundary for local network access. One thing the review explicitly left open: how proxy destination filtering works. That was outside its scope, so don't read this as a statement about what the proxy blocks.

Maya

Practically, that means anything listening on localhost, a dev database, an admin port, a debug server, is reachable from inside a managed network operation. Though I'd flag that as my reading of the loopback finding, not something the review tested.

Ethan Park

Fair framing. It's an implication to check against your own machine, not a proven exploit.

Maya

Now the part that I think catches people in practice: selection. If I configure MXC, am I guaranteed to be on it?

Ethan Park

No. In your config.toml, under the windows table, you can set sandbox equal to mxc. Or you can use automatic selection with prefer_mxc set to true under the features table. Automatic selection requires three things: the preference is enabled, the configuration allows it, and the native backend is available. An effective denial on local binding also invalidates MXC eligibility. If any check fails, Codex silently keeps its configured backend. That could be the legacy restricted token engine. And the sandbox manager can choose no sandbox at all under a Forbid setting. So a configured MXC backend does not prove every operation used it.

Maya

Silently is the word that worries me. No warning, no refusal.

Ethan Park

Right. There is one contrast. Once an operation explicitly enters the WindowsMxc transformation branch, an unavailable native backend raises an error instead of falling back. But that check sits downstream of automatic selection, so it won't catch the silent case.

Maya

So what do I actually do on Monday?

Ethan Park

Three steps. One, don't treat the backend as your network policy. If you want isolation, lock the permission profile directly. Under sandbox_workspace_write, set network_access to false. Two, if you use managed networking, treat all of loopback as reachable, and keep sensitive local services off that machine or behind authentication. Three, audit. Check dot codex slash dot sandbox slash sandbox.log to see what policy was generated, and verify whether managed networking proxies are configured. Confirm which backend an operation really used rather than assuming it from your config.

Maya

Now the small stuff, because there are three quality of life changes in 0.162.0 and 0.162.1 worth knowing. First, instant interrupt is now on by default, from PR 51812. New input immediately preempts model responses or long running code mode calls. It's still marked under development, so if you preferred the old behavior where input queued behind the response, set instant_interrupt to false under the features table.

Ethan Park

Second, CRLF line endings are now preserved in apply_patch universally, from PR 51203. If you work in Windows repos, patches stop rewriting your line endings. The temporary apply_patch_preserve_line_endings flag has been moved to removed, so you can delete it from your config. Third, PR 50209 adds mouse wheel scroll speed tuning for the fullscreen TUI. Under the tui table in config.toml, set mouse_scroll_speed to any finite positive number. The default is 1.0, and 1.5 makes it noticeably faster. So the takeaway: with MXC, choose the backend and the network policy as two separate decisions, then check the log to see what you got.