v0.107.0 Windows Sandbox ACL Failure (Error 5) and Unintended Permission Pollution on User Home Directory
What version of Codex CLI is running?
Microsoft Windows NT 10.0.26100.0 x64
What subscription do you have?
free
Which model were you using?
gpt-5.3-codex
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64
What terminal emulator and version are you using (if applicable)?
PowerShell：7.5.4
What issue are you seeing?
The new Windows sandbox logic in v0.107.0 fails to correctly apply ACLs when a workspace is located on a non-system drive (e.g., E:\).
Specifically, codex-windows-sandbox-setup.exe attempts to modify the security descriptor of the drive root (E:\), which results in a SetNamedSecurityInfoW failed: 5 (Access Denied) error.
Furthermore, the setup utility injects sandbox-related Capability SIDs into the host user's home directory (C:\Users\w), causing persistent "permission pollution" and leaving orphan SIDs after the session ends. This breaks the expected security isolation and NTFS inheritance.
What steps can reproduce the bug?
Install/Update Codex to v0.107.0 on a Windows machine.
Initialize a workspace on a separate NTFS partition (e.g., E:\projects).
Run a command that triggers workspace write access, such as: codex --workspace E:\projects "list files".
Observe the setup refresh had errors output in the terminal.
Inspect sandbox.log for permission failures and check the Security properties of the user's $HOME directory.
What is the expected behavior?
Expected:
Codex should only modify ACLs for the specific paths defined in writable_roots.
ACL modifications should not require permissions at the drive root level.
No permanent SIDs should be injected into the host's User Profile directory.
Actual:
Setup fails due to unauthorized drive root access.
The host user's directory ACL is "polluted" with sandbox SIDs.
Workspace write permissions are never stably established.
Additional information
Relation to PR #12741:
This regression appears to be directly introduced by the changes in PR #12741 (Add Windows direct install script).
The investigation shows that:
The new install.ps1 script triggers environment initialization that can lead to DotSourceNotSupported errors in constrained PowerShell environments.
The bundled Windows sandbox binaries (codex-windows-sandbox-setup.exe and codex-command-runner.exe), which were introduced/updated in that PR, are the ones performing the incorrect ACL operations.
The logic for path resolution in the new sandbox setup seems to incorrectly traverse up to the drive root (E:\) instead of staying within the defined writable_roots.
I recommend the authors of #12741 (specifically @EFRASER-oai) review the Win32 API calls for ACL management to ensure they are scoped correctly and do not require elevated privileges for non-system drives.