Codex Desktop on Windows: `.git/FETCH_HEAD: Permission denied` from sandbox-induced orphan-SID Deny ACEs

[PsyDocH1801]

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

• Codex Windows sandbox warning is transient, non-actionable, and causes silent Git failures #9341 — VS Code extension surface, .git/index.lock failure, same Windows sandbox cause
• Allow writable gitdir for current worktree in sandboxed workspace-write mode #14338 — Linux bubblewrap surface, same .git/FETCH_HEAD symptom, request for writable-gitdir opt-in
• Security concern: CodexSandboxOffline/Online assigned to entire user profile tree on Windows 11 #12343 — sandbox creates CodexSandbox* groups; can leave stale SIDs after uninstall
• v0.107.0 Windows Sandbox ACL Failure (Error 5) and Unintended Permission Pollution on User Home Directory #13378 — sandbox ACL setup leaves persistent permission pollution
• Desktop automations silently fall back to workspace-write sandbox regardless of app configuration #15310 — desktop automations falling back to workspace-write sandbox regardless of config

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Linux sandbox mounts linked worktree gitdir read-only after writable ancestor bind #19786

Powered by Codex Action

[PsyDocH1801]

Follow-up after testing on a disposable clone outside any OneDrive scope (C:\acl-test\Git-Obsidian-backup).

TL;DR

• The workaround cited in Codex Windows sandbox warning is transient, non-actionable, and causes silent Git failures #9341 ([features].experimental_windows_sandbox = false) is no longer functional. codex features list in CLI 0.128.0 reports both experimental_windows_sandbox and elevated_windows_sandbox as removed. Setting them in [features] is a no-op.
• The current sandbox knob is [windows].sandbox, which accepts only elevated (default) or unelevated — there is no off/disabled/none value. Setting any other value fails at config-load: unknown variant '<value>', expected 'elevated' or 'unelevated'.
• Both Codex Desktop modes (elevated, unelevated) and Codex CLI in workspace-write mode all reproduce error: cannot open '.git/FETCH_HEAD': Permission denied on a fresh clone outside OneDrive scope. The sandbox layer is the cause — not Git, not NTFS, not the repo, not any environmental factor.
• Control: codex exec --dangerously-bypass-approvals-and-sandbox -C <clone> "git pull --ff-only" succeeds with exit 0. That is the cleanest possible isolation of the sandbox as the operative factor.
• The ACL-pollution side-effect splits across modes:
  • Codex Desktop elevated: writes orphan-SID Deny ACEs on .git. Yes (host-visible).
  • Codex Desktop unelevated: same FETCH_HEAD failure, but no Deny ACEs written. The unelevated mode enforces via restricted-token semantics, not via DACL changes.
  • Codex CLI workspace-write: writes orphan-SID Deny ACEs (with a fresh per-session orphan SID, different from the Desktop one).

Detail

Test environment

Same as the original report: Codex Desktop 26.429.3425.0 (x64, Microsoft Store / WindowsApps install) + Codex CLI 0.128.0, Windows 11 Pro 26200, standard local user. Disposable clone outside OneDrive scope so any orphan-SID ACE that appears is causally attributable to Codex.

Test 1 — [windows] sandbox = "unelevated"

Procedure: edit ~/.codex/config.toml to set [windows] sandbox = "unelevated", fully exit Codex Desktop (kill all Codex processes), relaunch Codex Desktop, point at the disposable clone, run git pull --ff-only from inside Codex.

Result: identical error: cannot open '.git/FETCH_HEAD': Permission denied failure as the elevated mode. But host-side Get-Acl .git showed zero new explicit Deny ACEs — the DACL was byte-identical to the clean-baseline state from immediately after git clone.

Implication: the unelevated variant of the Windows restricted-token sandbox is "cleaner" in that it doesn't pollute host-visible ACLs, but it doesn't fix the underlying lockout. Whatever mechanism in unelevated mode prevents the sandbox from writing inside .git is independent of the DACL.

Test 2 — Codex CLI workspace-write

Procedure (from a host PowerShell session, with toml restored to elevated):

codex exec -s workspace-write -C C:\acl-test\Git-Obsidian-backup `
    "Run the shell command: git pull --ff-only. Then report exactly: (1) the command exit code, (2) any stdout, (3) any stderr."

Result: same error: cannot open '.git/FETCH_HEAD': Permission denied from inside the sandbox.

Post-test icacls C:\acl-test\Git-Obsidian-backup\.git:

S-1-5-21-1055846344-1817993210-866058223-1263234699:(DENY)(W,D,Rc,DC)
S-1-5-21-1055846344-1817993210-866058223-1263234699:(OI)(CI)(IO)(DENY)(W,D,Rc,GW,DC)
S-1-5-21-1055846344-1817993210-866058223-1263234699:(I)(OI)(CI)(M,DC)

Two explicit Denies + one inherited Allow against S-1-5-21-1055846344-1817993210-866058223-1263234699. From the host's POV this SID is orphan (Translate([NTAccount]) throws IdentityNotMappedException); its prefix matches no SID issuer registered with this Windows host's LSA. Same shape as the original report (S-1-5-21-3824534274-3844480456-2110850372-3580790307 from the original Codex Desktop pull): one direct Deny + one (OI)(CI)(IO) inherit-only Deny that propagates onto every newly-created child of .git.

This is the fourth distinct orphan SID family observed across testing (live repo, two disposable-clone sessions, plus a workspace-root Allow side-finding). The orphan SID is per-Codex-session, not per-machine.

Test 3 — control with --dangerously-bypass-approvals-and-sandbox

codex exec --dangerously-bypass-approvals-and-sandbox -C C:\acl-test\Git-Obsidian-backup `
    "Run: git pull --ff-only. Report exit code and stdout/stderr."

Result: exit 0, fast-forwarded cleanly. Sandbox unambiguously the cause.

Updated mechanism summary

1. The FETCH_HEAD lockout is universal across all sandboxed Codex modes (Desktop elevated, Desktop unelevated, CLI workspace-write tested; CLI read-only would presumably be the same). The only path that lets git pull --ff-only succeed is sandbox-bypass — exposed on the CLI as --dangerously-bypass-approvals-and-sandbox, not exposed as a config option in Codex Desktop.
2. The orphan-SID Deny ACE pollution is a side-effect of two specific modes: Desktop elevated and CLI workspace-write. Desktop unelevated reproduces the lockout without writing Denies.
3. The orphan SID is per-session, not per-machine. Four distinct orphan SIDs observed across testing.
4. From inside the sandbox the SID resolves to the sandbox's effective principal, otherwise the Deny would be a no-op there too. The host's Translate cannot see this principal because it lives in Codex's sandbox identity layer.

What this implies for the original report

The original report's "Workaround" section cited the experimental_windows_sandbox toggle pending local test. That section is now stale — the toggle no longer exists in CLI 0.128.0. There is currently no in-product way to disable the sandbox in Codex Desktop; the only working bypass is via Codex CLI's --dangerously-bypass-approvals-and-sandbox, which is not a comparable durable workflow (it disables the sandbox entirely for that exec, with all the safety implications that come with it).

The writable-gitdir opt-in proposed in #14338 for the Linux bubblewrap path remains the cleanest cross-platform fix.

In the meantime, the Codex Desktop unelevated variant is at least an improvement on elevated for the host-ACL-pollution dimension: same lockout, but no accumulating Deny ACEs that need a RemoveAccessRuleSpecific cleanup recipe to remove. If elevated cannot be deprecated entirely, surfacing unelevated as the recommended default would reduce surprise for users who don't realise their .git directories are accumulating orphan-SID Deny ACEs every Codex session.

[PsyDocH1801]

Correction and closure.

After the follow-up testing, I learned that Codex Desktop has an in-app "Full Access" toggle under settings that maps to sandbox_mode = "danger-full-access" + approval_policy = "never" — exactly the configuration that allows git pull --ff-only to succeed from inside Codex Desktop. The toggle is on by default in some installs (mine on the old laptop) and off in others (mine on the new laptop), which fully explains the asymmetry described in the original report.

The original report's framing was therefore wrong on its central claim ("no in-product way to disable the sandbox in Codex Desktop"). The toggle exists. This is a settings-discovery issue on my end, not a bug in Codex.

Two sub-concerns surfaced during testing that may still be worth tracking — but better as separate, focused issues than as a reframe of this one:

1. Discoverability. The in-sandbox error: cannot open '.git/FETCH_HEAD': Permission denied is a generic OS error with no Codex-side hint that the sandbox is the cause or that Full Access in settings would resolve it. I spent hours chasing OneDrive ACL theories before the sandbox layer became visible. A more specific in-app error or a one-line "this command was blocked by the sandbox; see settings → Full Access" would prevent the same chase for the next user.

2. ACL hygiene in elevated mode. Even when users keep Default Permissions (sandbox on), [windows] sandbox = "elevated" writes orphan-SID Deny ACEs on .git per session. From the host POV the SIDs don't translate (IdentityNotMappedException), so the ACEs are no-ops and don't break host Git, but they accumulate permanently in the NTFS DACL across sessions. [windows] sandbox = "unelevated" reproduces the same lockout from inside the sandbox without writing the Denies, so the pollution is specific to elevated mode rather than the sandbox layer in general. Worth noting if you're tracking sandbox-cleanup hygiene.

Neither rises to the level of the original framing. Closing this; happy to file the sub-concerns separately if either is of interest, otherwise the writable-gitdir cross-platform request in #14338 covers the underlying ergonomic ask.

Apologies for the noise.

[PsyDocH1801]

Closing per the correction comment above — original framing was wrong on its central claim. The Full Access toggle in Codex Desktop settings is the in-product disable I claimed didn't exist.