openaienmodel: gpt-5-mini-2025-08-07
Building a safe, effective sandbox for Codex on Windows
Key Points
- Used synthetic SIDs and write-restricted tokens for granular file writes
- Network suppression via env/PATH stubs was advisory and bypassable
- ACL-based approach was precise but costly and slow to change
Summary
The engineering team implemented an unelevated Windows sandbox prototype to let Codex run developer workflows with constrained file-write and network capabilities. The design used native Windows primitives (synthetic SIDs and write-restricted tokens) to grant granular write permissions to configured workspace roots while attempting to suppress outbound network access via environment overrides and PATH stubbing. The prototype worked but had performance, semantics, and security limitations that made its network protections unacceptable for a final product.
Key Points
- Goal: run Codex processes with reduced privileges without requiring administrator elevation while preserving developer productivity.
- File-write restrictions:
- Created a synthetic SID (sandbox-write) and applied ACLs to allow write/execute/delete to the current working directory and configured writable_roots.
- Launched Codex child processes under a write-restricted token whose restricted SID list included Everyone, the session SID, and sandbox-write, enforcing both normal and restricted-SID checks for writes.
- Explicitly denied write access to sensitive subpaths (e.g., .git, .codex, .agents) to keep parts of the checkout read-only.
- Network restrictions (unelevated, advisory):
- Used environment overrides and PATH reordering to make common tools fail-closed (examples: HTTPS_PROXY=http://127.0.0.1:9, GIT_HTTPS_PROXY, GIT_SSH_COMMAND=cmd /c exit 1, and a denybin directory for stub SSH/SCP).
- This approach caught many cases but is advisory: processes can bypass env vars, PATH, or open sockets directly.
- Tradeoffs and downsides:
- Applying ACLs across a workspace can be slow and expensive depending on directory topology.
- ACL-based semantics are invasive and hard to change quickly compared to macOS seatbelt-style configs.
- Network suppression without privileged firewall control is fragile and can be circumvented by adversarial or nonstandard networking implementations.
Practical implications for engineers
- Use synthetic SIDs + write-restricted tokens when you need per-process, fine-grained write policies on Windows without elevation, but expect setup and update costs for ACL changes.
- Don’t rely solely on environment-based network controls for security-critical network suppression; privileged OS mechanisms (firewall drivers or VM-level isolation) are required for robust blocking.
- Consider the developer UX tradeoffs: unelevated sandboxes reduce permission prompts but may require heavier engineering (ACL management, workspace scanning) to remain safe and performant.
Next steps (from the prototype outcome)
- The team rejected AppContainer, Windows Sandbox, and MIC as direct fits and concluded the unelevated prototype’s network protection was insufficient—driving further design work toward a stronger, more reliable network isolation approach.