Repository navigation
Sandbox backend for Windows (unelevated write protection) #381
Description
docs/ceilings.md records that Windows has no sandbox backend, so neither sandbox switch exists there. This issue parks the route that would close it, and the reason it stays parked for now.
The route
futuregene/future-os ships one, documented in desktop/DEV_MD/SANDBOX_PLAN.md §11 and implemented in agent/src/sandbox/windows/ (~3.6k lines of Rust). It is unelevated: the command still runs as the real user, with CreateRestrictedToken (DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED) plus a capability SID and NTFS ACLs drawing the write boundary. No sandbox account, no UAC, no elevated broker. Same primitives as Codex's unelevated backend, and the same ceiling.
It protects writes only — reads and the network stay open, which happens to match what our sandbox is for: confining a working agent, not hostile code.
Facts they measured on a real machine
The parts that are expensive to rediscover:
- PowerShell does not start with the capability SID alone — the CLR exits with
E_ACCESSDENIEDafter process start. It needs capability + logon SID + Everyone in the restricting set. - The real user SID must never enter
SidsToRestrict: it satisfies ordinary file ACLs and quietly voids the write boundary. - Admitting logon/Everyone as restricting SIDs means any existing object granting those SIDs write access can still pass the second access check. You cannot claim every out-of-workspace write is decided by the capability.
CreateWindowStationWreturnsERROR_ACCESS_DENIEDfor a normal user, so a separate window station is not a compatibility baseline; they use a private desktop onWinsta0instead.- An ACL only attaches to an object that already exists — it cannot deny a future filename or express a glob. Literal existing objects can be hardened, nothing more.
- The full-restricted-token route (restricting reads too) breaks
%APPDATA%, Cargo, rustup, npm, Git and Python badly enough that they dropped it.
Background reading: OpenAI's write-up on building the Codex Windows sandbox.
Why it is deferred
The effort is on the order of the whole ai-jail port, for the platform we treat as experimental and cannot exercise by hand. The Windows CI runners could prove the write boundary holds, but not the interactive lifecycle around it — and their own doc gates the feature behind a real-machine validation run for exactly that reason.
Worth revisiting when the Windows port stops being experimental, or when someone runs lich on Windows unattended and asks for it.
Activity
feat: name a worktree by the GitHub issue it is for (#459)