Add managed policy option to disable Windows sandbox ACL/DACL mutation

What variant of Codex are you using?

CLI, IDE Extension, and Codex App on Windows.

What feature would you like to see?

Please add a managed configuration option that lets administrators disable automatic Windows sandbox ACL/DACL changes on user-controlled paths.

Requested behavior:

• Codex may still perform first-time Windows sandbox provisioning:
• create/update CodexSandboxOffline
• create/update CodexSandboxOnline
• create/update CodexSandboxUsers
• set up Codex-owned helper/runtime/secrets directories needed for the sandbox
• Codex must not automatically add, remove, or rewrite allow/deny ACEs on:
• workspaces
• repositories
• user profile trees
• AppData
• .git
• additional writable/read roots
• arbitrary folders on other drives
• If the sandbox user does not already have the required NTFS rights, Codex should fail closed with a clear diagnostic:
• path
• required principal, e.g. CodexSandboxOffline or CodexSandboxUsers
• required right, e.g. read/execute or modify
• suggested manual icacls direction, without applying it automatically

Suggested config shape, exact naming flexible:

[windows]
sandbox = "elevated"
sandbox_acl_mode = "manual"

or in managed policy:

[windows]
sandbox_acl_mode = "manual"

Possible values:

automatic  # current behavior/default
manual     # never mutate workspace/user-path ACLs; fail if rights are missing

This should be enforceable from managed_config.toml so enterprise/admin-managed environments can require the safer mode globally.

Additional information

This is important for enterprise and security-controlled Windows environments.

Many IT/security teams do not want development tools silently changing NTFS DACLs because:

• ACLs are normally owned by endpoint management, GPO, Intune, security baselines, or deployment scripts.
• Silent inherited ACE changes can expand access across large profile/workspace trees.
• Unexpected deny ACEs can break Git, SSH, build tools, Electron/Chromium apps, and other software.
• Stale SIDs and modified ownership/permissions remain after uninstall or account cleanup.
• Auditors expect permission changes to be explicit, reviewable, and attributable.
• In regulated environments, failing closed is preferable to silently granting access.

For these environments, the desired model is:

1. Codex provisions the sandbox identities.
2. Administrators manually grant the required NTFS rights.
3. Codex runs only where those rights already exist.
4. Missing permissions produce a clear error instead of automatic ACL repair/mutation.

Related issues that appear to be in the same problem family:

• #14006 Windows sandbox may auto-apply NTFS deny ACE on world-writable workspace paths
• #12343 Security concern: CodexSandboxOffline/Online assigned to entire user profile tree on Windows 11
• #15777 Codex sandbox installation corrupts ACL on AppData
• #27236 Codex elevated Windows sandbox ACLs appear to break Electron/Chromium GPU sandbox for apps under AppData\Local
• #17179 Windows workspace-write sandbox can change project ownership to CodexSandboxOffline and cause persistent write failures
• #22044 Windows restricted-token sandbox issues around ACL/SID stamping

If maintainers consider this a duplicate of #14006, please treat this as a concrete proposed resolution: a managed, documented "manual ACL mode" for Windows sandboxing.