Skip to content

Sandbox backend for Windows (unelevated write protection) #381

Open

Description

@omartelo

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_ACCESSDENIED after 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.
  • CreateWindowStationW returns ERROR_ACCESS_DENIED for a normal user, so a separate window station is not a compatibility baseline; they use a private desktop on Winsta0 instead.
  • 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

  1. added
    enhancementNew capability or improvement
    deferredDeliberately postponed — not rejected
    platform:windowsWindows-only — the experimental port
    on Aug 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    deferredDeliberately postponed — not rejectedenhancementNew capability or improvementplatform:windowsWindows-only — the experimental port

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions