›_ Codex Issues
Codex Issues / #18918

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

Open 💬 11 comments Opened Apr 22, 2026 by whyrv
💡 Likely answer: A maintainer (viyatb-oai, contributor) responded on this thread — see the highlighted reply below.

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-<sandbox-domain>-<id>:(DENY)(W,D,Rc,DC)
S-1-5-21-<sandbox-domain>-<id>:(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 #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 #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_

View original on GitHub ↗

11 Comments

viyatb-oai contributor · 3 months ago

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

whyrv · 2 months ago

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 · 2 months ago

same issue here.

paltenburg · 2 months ago

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
  1. 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.
  1. Rebooting Windows and fully reinstalling Codex (including a clean install test) did not change that behavior.
  1. 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 · 2 months ago

@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 · 2 months ago

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,

RoboLagoon · 2 months ago

They use LLM to develop a feature, that development breaks something that worked before introducing a new set of bugs. They fix them and introduce again a new set of bugs. Their process repeats and we see thousands of bugs reported in this repo, claude code etc. at the same time. The whole process is a joke. Devs do much better job than those modern AI agents everyone is worshipping so much. I have never seen so many issues in the apps developed by humans.

whyrv · 2 months ago

This particular issue works well with Claude Code, Kimi-cli, etc. So, it is specific to Codex’s over-protection and requires the user to keep the backdoor unlocked in this scenario.

flumignano · 1 month ago

This is still happening to me.

h2cone · 27 days ago

I’m seeing the same thing on Windows in Codex app.

The UI says Full access, and Codex can edit normal files, but git add fails with:

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

There is no existing index.lock. The .git ACL has explicit Deny entries for Write/Delete, so this looks like the same DENY ACL issue.

The confusing part is that Full access is selected, but .git still isn’t writable.

olinkluzz1v · 7 days ago

I am experiencing what appears to be the same underlying bug in Codex Desktop on Windows 11, with two additional details: the repository is outside USERPROFILE, and the failure occurs in a linked Git worktree.

Sanitized setup

  • Codex Desktop on Windows 11
  • Managed workspace-write sandbox
  • A normal Git repository under a dedicated development directory
  • Implementation performed in a linked worktree
  • The worktree’s .git file resolves to the main repository’s .git/worktrees/<worktree> directory

Observed behavior

  1. Codex can modify ordinary source files.
  2. Git operations from the Codex sandbox fail when writing metadata:

fatal: Unable to create '.../.git/worktrees/<worktree>/index.lock': Permission denied

  1. ACL inspection shows explicit DENY entries on .git or the resolved linked-worktree Git directory for sandbox-created identities.
  2. The same git add and git commit commands succeed immediately in regular, non-administrator PowerShell.
  3. Explicitly allowing the repository and .git paths in the Codex workspace configuration does not overcome the Windows ACL denial.
  4. The problem recurs across Codex tasks and restarts.
  5. A remote push later succeeded, but updating the local remote-tracking ref failed because its lock file could not be created under .git.

This forces Codex to ask the user to stage and commit changes outside the app.

Expected behavior

  • Authorized repositories should permit Git metadata writes required for staging, commits, and local ref updates.
  • Linked worktrees should authorize the resolved .git/worktrees/<worktree> directory.
  • Sandbox ACL entries should not persist or accumulate across sessions.

The current workaround is running Git mutations in ordinary PowerShell. Administrator privileges are not required.