Windows sandbox hardening

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_