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:
- Configure Codex with:
- sandbox_mode = "workspace-write"
- [windows] sandbox = "elevated"
- Create a python workspace containing a local .venv with protobuf for instance (nb: this is just an exemple
- Run icacls on directories:
icacls ".\.venv\Lib\site-packages\google\protobuf\internal" - 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.
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Related but no duplicates.
For windows users, worktrees development are not functioning. this issue is applied to me currently since the first launch of codex. This situation getting us worse in productivity and ci/cd. Those who see this issue and are on the same situation, give thumbs up to the issue; otherwise we won't get a full functionality with codex.
We reproduced a related Windows cross-turn helper lifecycle failure with an inert file and no product source:
apply_patchcreated one inert probe file successfully. The only recorded evidence was bounded size/hash/status metadata; diff check passed.apply_patchattempt to reopen that exact probe and replace a fixed non-sensitive marker failed before write:windows sandbox failed: helper_unknown_error: apply deny-read ACLsExpected: a file created by the helper can be reopened and semantically updated by the same helper in a fresh turn, then reopened and reverted in another fresh turn.
Actual: create succeeds, but the fresh-turn reopen/update fails before write. This makes new-file creation and temporary marker success insufficient as a capability probe for the next real operation.
No retry, ACL mutation, bypass, shell write, temporary copy, source read, secret, user data, provider data, endpoint, or absolute local path is included. We can provide the bounded three-boundary harness shape if useful.