Windows sandbox applies DENY ACLs to .git directories in writable_roots, breaking git commits

[whyrv]

What version of Codex CLI is running?

0.122.0

What subscription do you have?

PRO

Which model were you using?

gpt-5.4

What platform is your computer?

Windows 11 PRO

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

Gitbash/Powershell

What issue are you seeing?

Summary

After updating to the version released ~2026-04-20, Codex applies DENY ACEs to .git directories inside any path listed
in writable_roots, permanently breaking git commit (and any operation requiring .git/index.lock) for the sandboxed
process.

Root Cause

PR #18443 changed sandbox ACL setup to expand USERPROFILE into its direct children rather than granting the root. For
users whose repos live under a USERPROFILE child (e.g. C:\Users\me\OneDrive...), those repos are now in scope for
sandbox ACL grants. The sandbox applies DENY ACEs to the repo's .git directory — presumably to protect git history —
but those DENY ACEs are not cleaned up and persist after Codex exits, reapplied on every startup.

Observed Behavior

fatal: Unable to create '.../.git/index.lock': Permission denied

icacls .git shows explicit DENY ACEs for the sandbox SID:

.git S-1-5-21--:(DENY)(W,D,Rc,DC)
S-1-5-21--:(OI)(CI)(IO)(DENY)(W,D,Rc,GW,DC)

• The DENY SID is the Codex sandbox identity (different domain from the local machine SID)
• Removing the ACEs manually with icacls /remove:d works temporarily
• Codex reapplies the DENY ACEs on next startup
• The user's own account (vasan) retains full control and is unaffected — only the sandboxed process is blocked

Environment

• OS: Windows 11 Pro
• Codex version: updated ~2026-04-20 (post-PR Do not grant Windows sandbox ACLs on USERPROFILE #18443)
• sandbox_mode = "workspace-write", [windows] sandbox = "elevated"
• Repo path: under C:\Users<user>\OneDrive... (OneDrive is a direct USERPROFILE child, so it falls into the expanded
  roots after Do not grant Windows sandbox ACLs on USERPROFILE #18443)

Expected Behavior

.git directories inside writable_roots should be excluded from DENY ACE grants, consistent with how .ssh is excluded.
Git operations must work from within the sandbox.

Suggested Fix

In codex-windows-sandbox, add .git to the same exclusion list used for .ssh, .tsh, .brev. Apply the same pattern PR
#18493 uses for SSH config scanning — just statically exclude .git at any depth within a writable root, since the
sandbox has no legitimate reason to DENY-lock version control internals.

// alongside .ssh, .tsh, .brev exclusions:
".git",

What steps can reproduce the bug?

create .git under onedrive and have codex commit to it -- was working flawlessly till this upgrade.

What is the expected behavior?

"• I found the root cause: ACL on .git has an explicit DENY write entry for the Codex sandbox SID, so this
session cannot create index.lock (staging/commit blocked). I’ll try removing that deny ACE and then
finish commit/issue closeout." -- per codex itself

Additional information

No response

[viyatb-oai]

@whyrv this made windows sandbox consistent with behavior on macos and linux. in workspace-write sandbox mode, writes to .git are not allowed.

[whyrv]

What is the workaround to restore old behavior: sandbox = "unelevated" doesn't seem to help either. The original behavior was working for months until this breaking change.

[ywkuno]

same issue here.

[paltenburg]

Additional Windows desktop repro details from my setup, in case this helps narrow it down.

Environment:

• Codex desktop app on Windows
• repo at D:\Develop (so not under C:\Users\... / not under OneDrive)
• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"

What I observed before switching to full access:

1. The visible Codex terminal and the autonomous backend tools were not running with the same effective identity.

   • Visible Codex terminal: whoami -> popke-dell-pc\palte
   • Autonomous backend tool path: whoami -> popke-dell-pc\codexsandboxonline

2. In that state, the visible Codex terminal could write under .git, but the autonomous backend tool path could not.

   • Visible terminal succeeded with:
     • New-Item -Path D:\Develop\.git\index.lock -ItemType File -Force
     • Remove-Item D:\Develop\.git\index.lock -Force
   • Backend tool failed on a plain write under .git with:
     • Set-Content D:\Develop\.git\tool-check.tmp ok
     • error: Access to the path 'D:\Develop\.git\tool-check.tmp' is denied.

3. Rebooting Windows and fully reinstalling Codex (including a clean install test) did not change that behavior.

4. Switching Codex to danger-full-access immediately changed the backend tool behavior:

   • backend tool whoami became popke-dell-pc\palte
   • backend tool could then write under .git
   • after that, autonomous Git writes/commits started working again

So there seem to be two useful data points here:

• This reproduces on a repo outside C:\Users\..., at least in the desktop app.
• In workspace-write, there is a Windows desktop identity split where the visible terminal can access .git, but autonomous backend tool execution still runs as the sandbox user and cannot.

Workaround on my machine:

• sandbox_mode = "danger-full-access"

That is the only setting that restored autonomous Git writes for me.

[rentanything-nb]

@paltenburg , danger-full-access is exactly that... CODEX now has unrestricted access to do anything on your system. @viyatb-oai , I'll say the same thing I said in the other thread: Confirming that a change which made the product unusable is not an acceptable response to a bug report

[whyrv]

sandbox_mode = "danger-full-access" works for me. So the fix from open-ai is to make the sandbox less secure by the user to go back to a working state,