codex - 💡(How to fix) Fix Codex Desktop on Windows: `.git/FETCH_HEAD: Permission denied` from sandbox-induced orphan-SID Deny ACEs [4 comments, 2 participants]

Environment

• Codex Desktop: 26.429.3425.0 (x64, Microsoft Store / WindowsApps install)
• OS: Windows 11 Pro 26200
• Repo: fresh git clone of a public GitHub repo into C:\Repos\<repo>\ (path outside any OneDrive scope)
• Account: standard local user, not Administrator
• Codex CLI 0.128.0 also installed on the same machine; not used for this reproduction

Summary

git pull --ff-only from inside Codex Desktop fails with error: cannot open '.git/FETCH_HEAD': Permission denied. From a normal PowerShell session as the same user against the same path, git pull --ff-only succeeds.

After Codex Desktop's first contact with the repo, host-side Get-Acl .git shows two new explicit Deny ACEs against an "orphan" SID — orphan from the host's IdentityNotMappedException POV but evidently resolving inside the Codex Desktop sandbox to the sandbox's effective principal, since that's the only thing that explains why Codex's own writes inside .git are blocked while host writes succeed.

Reproduction

1. Fresh git clone into a path outside any OneDrive Known Folder Move scope. Confirm the freshly-cloned .git carries zero explicit Deny ACEs and no orphan SIDs (icacls <repo>\.git should show only inherited BUILTIN\Administrators (F), NT AUTHORITY\SYSTEM (F), BUILTIN\Users (RX), NT AUTHORITY\Authenticated Users (M)).

2. Open a fresh Codex Desktop session pointed at the clone.

3. Have Codex run git pull --ff-only.

4. Observe the failure inside Codex: error: cannot open '.git/FETCH_HEAD': Permission denied.

5. Re-run icacls <repo>\.git from a normal host PowerShell session. Two new explicit Deny ACEs are present:

   <orphan-SID>:(DENY)(W,D,Rc,DC)
   <orphan-SID>:(OI)(CI)(IO)(DENY)(W,D,Rc,GW,DC)

   The (OI)(CI)(IO) ACE propagates onto every newly-created child of .git, which is what blocks FETCH_HEAD write on the next pull attempt.

Mechanism (hypothesis)

The "orphan" SID has the same shape as a normal machine SID (S-1-5-21-<machine>-<RID>) but its machine prefix matches no SID issuer registered with this Windows host's LSA, so IdentityReference.Translate([NTAccount]) throws IdentityNotMappedException. From the host's POV the Deny is a no-op — that matches the observation that host PowerShell Git operations succeed through these ACEs.

From the Codex Desktop sandbox's POV, however, the same SID resolves to the sandbox's effective principal — otherwise the Deny would be a no-op there too. So Codex Desktop is locking itself out of .git on every clone it touches.

Confirming side-observation: on first contact with a workspace root, Codex Desktop adds two Allow ACEs at the workspace root level — one for the documented CodexSandboxUsers group (expected), and one for a different orphan SID. The Allow case is harmless (Allow for an unmappable SID is a no-op from host POV). The Deny case is the Git breakage.

This appears to be the Windows-native-sandbox manifestation of the same design pattern documented for the Linux bubblewrap path in #14338 (.git/FETCH_HEAD: Read-only file system because bubblewrap mounts .git read-only after writable roots are applied) and reported on the VS Code extension surface in #9341 (.git/index.lock: Permission denied from the same Windows sandbox layer).

Suggested triage

A writable-gitdir opt-in along the lines requested in #14338 would address the underlying design constraint cross-platform.

In the meantime, the Windows sandbox lockout produces a generic "Permission denied" with no in-sandbox indication that the Codex sandbox is the cause. #9341 covered that visibility ask for the VS Code extension surface; the same applies to Codex Desktop standalone. A persistent, in-app indicator that the experimental Windows sandbox is active and that Git operations against .git inside the workspace will fail would prevent users from spending hours diagnosing this as a OneDrive / antivirus / NTFS ownership issue (which is exactly the path that led to filing this report).

Workaround

#9341's reporter confirmed that experimental_windows_sandbox = false in ~/.codex/config.toml resolved their .git/index.lock failure. We have not yet tested this against the FETCH_HEAD reproduction locally; planning to test on a disposable clone next and will follow up here.

Operational workaround in use: never let Codex Desktop run Git operations on this repo. Host PowerShell as the standard user runs all Git; Codex Desktop is restricted to non-Git file edits. That works because the orphan-SID Deny ACEs are no-ops from host POV.

Related issues

• #9341 — VS Code extension surface, .git/index.lock failure, same Windows sandbox cause
• #14338 — Linux bubblewrap surface, same .git/FETCH_HEAD symptom, request for writable-gitdir opt-in
• #12343 — sandbox creates CodexSandbox* groups; can leave stale SIDs after uninstall
• #13378 — sandbox ACL setup leaves persistent permission pollution
• #15310 — desktop automations falling back to workspace-write sandbox regardless of config