Windows: restricted token, firewall filter, and two dedicated system users

A teammate runs Codex on a Mac; the agent touches an SSH private-key path in the user profile; Seatbelt stops it at once, and the error says Operation not permitted. Put the same read on Windows and the error becomes Access is denied. Switch to a machine that never turned on the Windows sandbox, and the command may never reach an ACL — execpolicy already marks it Forbidden or Prompt.

Three machines, one intent, three failures. The next sentence the model sees is different, so the next step changes with it. If Windows pretends it has the same default sandbox as Unix, the model plans as if it is confined — while the command runs naked.

macOS limits which operations this process may do on which paths. Linux limits what this process can see and which syscalls it can make. Windows has no namespace and no seccomp. Codex asks a different question: which resources can this identity touch.

The token decides who you are. The RestrictedToken tier cuts from the current-user token; the Elevated tier logs in with a dedicated account first, then cuts from that token. Both ends land on the same flags: DISABLE_MAX_PRIVILEGE, LUA_TOKEN, WRITE_RESTRICTED. Privileges are thinned; a write must pass both the ordinary ACL and a restricting-SID cross-check.

At the RestrictedToken tier, reads still follow the current user. The source says so itself: a capability-SID deny-read ACE on a WRITE_RESTRICTED token does not join the read check, so read limits must go through Elevated; a naked run is refused outright.Source: codex-rs/windows-sandbox-rs/src/token.rs line 480；codex-rs/sandboxing/src/windows.rs lines 109–117

What a subject can do, and who may touch an object, are two isolation primitives. Rewrite it in another language: Windows still has no bwrap to call. The question remains: do you have an identity, and what is that identity allowed to touch.

The wrap is the same family of self-invocation. Windows uses its own exe plus a hidden --run-as-windows-sandbox flag — the same idea as Linux rewriting arg0.Source: codex-rs/windows-sandbox-rs/src/wrapper.rs line 20

WFP is the Windows Filtering Platform, a kernel packet-filter framework. It and the firewall rules both match on SID. One SID can carry only one network policy. The same identity cannot mean “no network at all” and also “may use a proxy or go outbound.”

So two local users become two network identities: CodexSandboxOffline and CodexSandboxOnline. from_permissions picks Offline when a proxy is forced, or when network policy is off. The offline identity installs outbound blocks, a proxy-port allowlist, then 12 WFP rules covering ICMP, DNS 53, DNS-over-TLS 853, and SMB. The online identity does not install that block set.

Unix network isolation swaps the NIC view the process sees. WFP leaves the process on the host network stack; only certain traffic from this SID is blocked. The process can still see NICs, fail DNS, and connect to other ports.

Filters are identified by stable GUIDs, carry a persist flag, and survive reboot. Uninstall and crash do not tear them down automatically. The repo has no function that deletes the users or removes WFP. A WFP failure is written as non-fatal; a firewall failure fails the whole setup.Source: codex-rs/windows-sandbox-rs/src/setup.rs lines 50–51、lines 706–714；codex-rs/windows-sandbox-rs/src/wfp.rs lines 69–95

When access control is by identity, the number of identities must cover the number of policy combinations. Two network-policy tiers need two identities. It is the same as two badge cards for two buildings — independent of WFP as a concrete API.

Someone will ask why not AppContainer. Its default readable range is narrow; arbitrary-path reads require changing the host DACL. Codex needs the workspace readable, the platform root readable, then hollow-outs from a deny list. A restricted token plus ACL fits this permission model better. Search AppContainer under codex-rs/ and business code has zero hits. The comparison repo DeepSeek Harness writes the same judgment in plain text: AppContainer cannot do arbitrary-path reads.

For Elevated to also govern reads and the network, you must create accounts, pop UAC, and change the firewall and WFP. Enterprise policy may forbid creating local users. Setting the default to Disabled leaves that product friction for the first enable.

The enum itself writes the default as off. If windows.sandbox is unset and both legacy flags are absent, it falls back to Disabled. The legacy flags are already marked Removed.

pub enum WindowsSandboxLevel {
    #[default]
    Disabled,
    RestrictedToken,
    Elevated,
}

After it is off, the platform sandbox is truly gone. get_platform_sandbox(false) returns empty on Windows; select_initial turns that into SandboxType::None. The command may still be stopped at the policy layer. A Windows test locks this in: with no backend, a read-only profile plus Never approval means unmatched cmd.exe /c dir must be Decision::Forbidden.Source: codex-rs/sandboxing/src/manager.rs lines 62–72、line 301；codex-rs/core/src/exec_policy_windows_tests.rs lines 113–130

Isolation depth is tied to the install budget. If you only want to stop the model from accidentally editing the repo, a current-user restricted token is enough. To stop secrets being read and sent off this machine, you also need read limits and identity-based network filtering. Promise a wall you cannot build, and both the model and the user will decide against that wall.

When platforms are unequal, the public story must be written against the layer that is actually on. macOS has Seatbelt by default; Windows may default to Disabled. Users who hear “there is a sandbox” will think three machines share one wall.