Windows sandbox hardening

Open 💬 2 comments Opened May 21, 2026 by oxsignal

What variant of Codex are you using?

CLI and Desktop

What feature would you like to see?

One more hardening suggestion for the Windows sandbox:

When the workspace/write root is %USERPROFILE%, Codex expands it into top-level user-profile children. This can include sensitive locations such as OneDrive, AppData, Documents, Downloads, Desktop, and similar profile directories.

Even if recent patches prevent stale capability SIDs from being reused across unrelated workspaces, the filesystem ACL setup can still leave Codex-related ACEs on these profile child directories. In my environment I had to manually clean up stale CodexSandboxUsers / capability SID ACEs from several user-profile paths.

I think %USERPROFILE% should either be rejected as a workspace write root, or sensitive profile children should be excluded by default. At minimum, locations such as the following should not receive broad writable ACLs:

%APPDATA%
%LOCALAPPDATA%
%USERPROFILE%\OneDrive
%USERPROFILE%\Documents
%USERPROFILE%\Desktop
%USERPROFILE%\Downloads
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup

Developer-tool caches that normally live under AppData should be redirected to a Codex-controlled cache/temp directory instead of granting broad AppData write access.

I also recommend adding an uninstall/cleanup path for Windows sandbox state. If Codex is uninstalled or the Windows sandbox is reset, it should remove the local Codex sandbox users/groups and clean up Codex-created ACEs from the user profile. Otherwise, stale CodexSandboxUsers / capability SID ACL entries can remain on disk indefinitely after the product is removed.

Additional information

_No response_

View original on GitHub ↗

2 Comments

pattharasit4-cmyk · 3 months ago

4 minutes to auto-flag a human, evidence-backed report as a "potential duplicate" — but a sandbox that hands CodexSandboxUsers Modify on the entire C:\ root shipped to release. Priorities 😌

For the record: #23912 is %USERPROFILE%, this is the drive root, reproduced post-redesign with icacls. Not a dup. Keeping it open.

oxsignal · 3 months ago

4 minutes to auto-flag a human, evidence-backed report as a "potential duplicate" — but a sandbox that hands CodexSandboxUsers Modify on the entire C:\ root shipped to release. Priorities 😌 For the record: #23912 is %USERPROFILE%, this is the drive root, reproduced post-redesign with icacls. Not a dup. Keeping it open.

It seems like you created an issue similar to mine. In my opinion, the biggest issue is that the folder permissions still remain even after uninstalling Codex or removing the session.