[Windows] CodexSandboxUsers gets Modify on C:\ root + orphan SIDs persist (post-redesign, follow-up #12343)

Resolved 💬 3 comments Opened May 23, 2026 by pattharasit4-cmyk Closed Jun 7, 2026

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/codex 0.130.0
  • Windows 11
  • Elevated (default) sandbox; .sandbox-secrets/sandbox_users.json is version: 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\Temp
  • C:\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 (the
system32, 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. under
Documents\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 the
ProfileList 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

  1. Windows 11, install @openai/codex 0.130.0.
  2. Run codex once in any project with the default elevated sandbox.
  3. icacls C:\ -> observe CodexSandboxUsers:(OI)(CI)(M,DC) plus an unresolved

S-1-5-21-... SID at the drive root.

  1. icacls "%USERPROFILE%\Documents\codex" and other workspaces -> observe

accumulating unresolved SIDs.

---

Suggested fixes

  1. Never place the workspace ACE on a drive root — scope strictly to the actual project directory.
  2. Reuse one stable sandbox SID instead of writing a new synthetic per-folder SID each run (stops accumulation).
  3. On uninstall, remove all ACEs, the local users, the CodexSandboxUsers group, the profile folder, and the ProfileList registry entry.
  4. Document the exact filesystem/account footprint and ship a codex sandbox cleanup command.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗