[Windows] CodexSandboxUsers gets Modify on C:\ root + orphan SIDs persist (post-redesign, follow-up #12343)
Follow-up to #12343.
After the May 2026 Windows sandbox redesign (two-account model + DPAPI-protected
credentials), the credential and network-isolation concerns are clearly
improved. However, the over-broad filesystem ACL grant and orphan-SID
pollution originally reported in #12343 still occur on the current build.
Evidence below is from a live machine (paths/usernames anonymized).
Environment
@openai/codex0.130.0- Windows 11
- Elevated (default) sandbox;
.sandbox-secrets/sandbox_users.jsonisversion: 5(DPAPI)
---
What still happens
1. CodexSandboxUsers receives Modify on the C:\ drive ROOT, inheritable
icacls C:\:
C:\ <HOST>\CodexSandboxUsers:(OI)(CI)(M,DC)
S-1-5-21-3337210627-...-90929294:(OI)(CI)(M,DC) <-- synthetic, unresolved
BUILTIN\Administrators:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(RX)
(M,DC) = Modify + Delete-child; (OI)(CI) = inherited to all children.
Because the ACE sits on the drive root, the sandbox identities (which are
real, logon-capable local accounts) effectively get Modify on every
inheritance-enabled folder under C:\ (user data, ProgramData, etc.).
OS directories hardened by TrustedInstaller (e.g. C:\Windows\System32) are
spared — verified clean — but everything inheriting from the root is not.
2. The same broad ACE appears on many other locations
<HOST>\CodexSandboxUsers:(OI)(CI)(M,DC) + a synthetic per-folder SID were found on:
- every project workspace (e.g.
D:\<project>) C:\Users\<USER>\Documents\codex(and subfolders)C:\Users\<USER>\AppData\Local\TempC:\tmp
3. ~/.codex/cap_sid tracks whole drives and System32 as workspaces
The internal map assigns a workspace SID to entries including c:/, d:/,e:/, and even c:/windows/system32. Not all are written to disk (thesystem32, d:\, e:\ roots were clean), but c:\ is.
4. Orphan / unresolved SIDs accumulate across runs
Beyond the current per-folder SID, additional unresolved S-1-5-21 SIDs remain
from earlier runs. Iterating the 37 entries in cap_sid: 24 folders carry
written SIDs, several with 2-3 leftover SIDs each (e.g. underDocuments\codex, a global "workspace" SID and a "writable-root" SID recur on
many subfolders). These persist after npm uninstall -g @openai/codex, together
with the local users, the CodexSandboxUsers group, the profile folder, and theProfileList registry key — matching the "dirties the environment with lingering
SIDs" complaint in #12343.
---
What is improved (credit where due)
- Credentials are DPAPI-encrypted in
.sandbox-secrets\sandbox_users.json(not plaintext). - That folder explicitly DENYs
CodexSandboxUsers; only owner / SYSTEM /
Administrators can read it.
- The offline/online split for network isolation is in place.
So credential theft is non-trivial now. The remaining problem is purely the
filesystem ACL scope + leftover SIDs.
---
Impact
- Least privilege is broken: sandbox identities can modify the majority of
C:\, not just the active project. If a sandboxed process is ever compromised,
the blast radius is most of the user's data.
- Persistent pollution: unresolved SIDs litter ACLs and survive uninstall.
- Undocumented: the drive-root grant and SID accumulation are not surfaced to the user.
---
Reproduction
- Windows 11, install
@openai/codex0.130.0. - Run codex once in any project with the default elevated sandbox.
icacls C:\-> observeCodexSandboxUsers:(OI)(CI)(M,DC)plus an unresolved
S-1-5-21-... SID at the drive root.
icacls "%USERPROFILE%\Documents\codex"and other workspaces -> observe
accumulating unresolved SIDs.
---
Suggested fixes
- Never place the workspace ACE on a drive root — scope strictly to the actual project directory.
- Reuse one stable sandbox SID instead of writing a new synthetic per-folder SID each run (stops accumulation).
- On uninstall, remove all ACEs, the local users, the
CodexSandboxUsersgroup, the profile folder, and theProfileListregistry entry. - Document the exact filesystem/account footprint and ship a
codex sandbox cleanupcommand.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗