Windows elevated sandbox does not recursively grant usable ACLs to existing workspace files

What version of Codex CLI is running?

codex-cli 0.115.0

What subscription do you have?

Team

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Windows Terminal (WSL / PowerShell)

What issue are you seeing?

When Codex runs on Windows with sandbox_mode = "workspace-write" and [windows] sandbox = "elevated", commands can enumerate files inside the workspace but cannot reliably open existing files under the workspace tree, especially inside .venv. This breaks Python imports and native extension loading during uv run pytest.

The failure reproduces as Access is denied / PermissionError on .py, .pyd, and .dll files inside the workspace, even though their parent directories are visible.

What steps can reproduce the bug?

Steps:

1. Configure Codex with:

• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"

1. Create a python workspace containing a local .venv with protobuf for instance (nb: this is just an exemple
2. Run icacls on directories: icacls ".\.venv\Lib\site-packages\google\protobuf\internal"
3. Run icacls on some .pyd file: icacls ".\.venv\Lib\site-packages\numpy\core\_multiarray_umath.cp311-win_amd64.pyd"

Current observation:

• The directory icacls succeeds and shows sandbox-related ACEs.
• The file-level icacls commands fail with: Access is denied

What is the expected behavior?

Should be able to access .pyd / .dlls

Additional information

Impact:
This breaks common Windows workflows in elevated sandbox mode for languages and toolchains that load many existing files from the workspace, especially:

• Python virtual environments
• native extension modules
• test runners and language servers

Root Cause Hypothesis
The elevated sandbox setup grants ACLs at the workspace root with inheritable ACEs, but does not recursively repair ACLs on existing descendant files. Existing directories can show sandbox ACEs while existing files beneath them still return Access is denied.
(Might also be due to some previous version of Codex that incorrectly setuped acl)

Suggested Fix
Add a way to recursively apply or repair effective ACLs for existing descendants under workspace write roots, not just the root directory.