Windows: approved .git write grant remains ineffective; sandbox setup JSON EOF

What version of the Codex App are you using (From “About Codex” dialog)?

Desktop app version not captured; bundled CLI reports codex-cli 0.155.0-alpha.9. Observed September 18, 2026.

What subscription do you have?

Not verified for this report.

What platform is your computer?

Windows; registry reports 25H2, build 26220.9472. Native elevated sandbox, workspace-write, local C-drive Documents workspace.

What issue are you seeing?

A path-specific filesystem write grant for the project .git directory was reported approved for the turn, but git add in that same turn failed to create .git/index.lock: Permission denied. Restarting the app and requesting the narrow grant again did not resolve it. Source edits and read-only git status worked; publishing remained blocked. The earlier task recorded explicit Deny Write/Delete ACL entries for sandbox identities on .git, while the Windows user had FullControl. No ACLs or sandbox settings were manually changed.

A separate later browser-tool startup failed with helper_unknown_error: apply deny-read ACLs. Resetting the browser-tool session restored access. Its relationship to the Git failure is unknown. Dated sandbox logs reveal an EOF parsing deny_read_acl_state.json; see below.

What steps can reproduce the bug?

Observed sequence (not a fresh minimal reproduction):

1. Use Codex desktop on Windows with [windows] sandbox = "elevated" and a workspace-write task.
2. Request write access specifically to the project .git directory through request_permissions.
3. The tool reports the path granted for the turn.
4. Run git add in that turn: .git/index.lock cannot be created, Permission denied.
5. Restarting and repeating the narrow request did not resolve the earlier failure.

The later browser startup error coincided with two setup refresh processes starting 2ms apart. The evidence does not establish a causal connection between these two failures. No secrets or private session contents are included.

What is the expected behavior?

An approved path-specific write grant should permit the requested Git operation, or the permission tool should explicitly report that the protected path cannot be granted. Sandbox setup should not fail while reading its own state file. Please advise a supported recovery that preserves sandbox protections.

Additional information

Reviewed excerpts from .sandbox/sandbox.2026-09-18.log (paths redacted):

18:24:45.494 and 18:24:45.496: two setup refresh processes spawned for the same workspace, payload_len=3244
[2026-09-18T22:24:45.558557800+00:00] setup error: apply deny-read ACLs
Caused by:
  0: parse deny-read ACL state [CODEX_HOME]/.sandbox/deny_read_acl_state.json
  1: EOF while parsing a value at line 1 column 0
[2026-09-18T22:24:45.562863100+00:00] top-level error: apply deny-read ACLs
18:24:45.578: setup refresh exited with status ExitStatus(ExitStatus(1))
22:24:45.628680100+00:00: setup refresh processed 4 write roots (read roots delegated); errors=[]
18:24:45.628: setup binary completed
22:24:45.729836700+00:00: read-acl-only mode: applying read ACLs
22:24:45.757941700+00:00: read ACL run completed
18:25:46.641 and .643: two subsequent setup refresh starts
22:25:46.720 and .730: processed 4 write roots; errors=[]
22:25:46.783: interleaved messages: read ACL helper already running; skipping / read-acl-only mode: applying read ACLs

Other nearby messages: SetFileAttributesW failed for C:/Users/Default: 5 (Access is denied.), while hiding a profile directory. The version command warned it could not find the home directory while creating PATH aliases.

No index.lock or 1385 match was found in the September 18 sandbox log searched. The original index.lock failure was recorded in earlier task output and was not freshly reproduced during this follow-up. Dated logs are readable; the undated .sandbox/sandbox.log does not exist.

Could concurrent setup read a partially written state file? This is a hypothesis, not a confirmed cause. Automated Help Center support reviewed these details and directed us here; no human case number was provided. Private user paths, credentials and sandbox secrets are omitted.

Start by comparing the concurrent setup-refresh entries in .sandbox/sandbox.2026-09-18.log with [CODEX_HOME]/.sandbox/deny_read_acl_state.json, keeping the Git grant failure separate from the browser-tool error. Investigate whether overlapping refreshes can observe an incomplete state file and whether the .git grant is rejected or ineffective. Done means the failure is reproducible or explained, with protected paths preserved and unsupported grants reported explicitly.