[Windows Desktop regression] Git writes stopped after 26.707.3748 → 26.707.6957 update; workspace-write DENY ACL blocks linked worktrees

[olinkluzz1v]

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

26.707.8479.0

What subscription do you have?

Pro

What platform is your computer?

Windows 11

What issue are you seeing?

Summary

Codex Desktop on Windows stopped being able to perform autonomous Git metadata writes after the application updated from 26.707.3748.0 to 26.707.6957.0.

Before this update, I used Codex Desktop for multiple pull requests over several days, including autonomous staging, commits, pushes, CI fixes, and PR lifecycle work.

After the update, a newly created linked worktree allowed Codex to edit, build, and test ordinary files, but every operation requiring writes to Git metadata failed because the Windows sandbox could not create lock files under the resolved worktree Git directory.

The same Git commands succeeded immediately in ordinary, non-administrator PowerShell.

This report expands on the symptoms already discussed in:

• Issue #18918: Windows sandbox applies DENY ACLs to .git directories
• My linked-worktree reproduction comment on #18918

The new evidence here is the exact local Codex Desktop package-update timeline, which strongly correlates the regression with the 26.707.3748.0 → 26.707.6957.0 transition.

Environment

• Platform: Windows 11 x64
• Codex Desktop, native Windows execution
• Current affected Desktop package: 26.707.8479.0
• First apparently affected package: 26.707.6957.0
• Last package under which previous PR workflows worked: 26.707.3748.0
• Model: gpt-5.6-sol, although this is not model-specific
• Sandbox mode: workspace-write
• Windows sandbox: [windows] sandbox = "elevated"
• Repository location: dedicated development directory outside USERPROFILE and outside OneDrive
• Repository type: normal Git repository using linked worktrees
• GitHub authentication: healthy and unrelated to the local failure
• Ordinary PowerShell: non-administrator and able to perform the same Git operations successfully

A later project-specific permission profile explicitly granted write access to the repository and .git, but Windows ACL denial still took precedence.

Confirmed application-update timeline

Windows Microsoft-Windows-AppXDeploymentServer/Operational events recorded these package transitions:

Local time	Package transition
2026-07-12 21:57	26.707.3748.0 → 26.707.6957.0
2026-07-13 01:30	A fresh linked worktree for the affected PR was created
2026-07-13 06:38	26.707.6957.0 → 26.707.8168.0
2026-07-13 17:29	26.707.8168.0 → 26.707.8479.0

The first affected linked worktree was therefore created approximately three and a half hours after the update to 26.707.6957.0.

Earlier PRs completed successfully after the relevant upstream source changes had been merged, but before these Desktop packages reached this machine. This suggests the source merge date and Desktop rollout date should not be treated as the same event.

I cannot confirm which exact public source commit is bundled in each Desktop package because there does not appear to be a public Desktop-build-to-source-commit mapping. The package transition is therefore strong correlation, not a claim of proven source-level causation.

Repository and worktree structure

The repository is outside the user profile:

C:\Dev\[repository]

The linked worktree is beneath the repository:

C:\Dev\[repository]\.worktrees\[worktree]

The worktree’s visible .git file resolves to:

C:\Dev\[repository]\.git\worktrees\[worktree]

That resolved directory contains the worktree index and is where Git must create index.lock.

Observed behavior

Codex can successfully:

• Inspect and modify ordinary source files
• Run formatters
• Restore dependencies
• Build the solution
• Run unit and integration tests
• Inspect Git state
• Access GitHub
• Push an already-created commit to the remote repository

Codex cannot successfully:

• Stage changes
• Create commits
• Refresh the Git index
• Update local refs
• Update local remote-tracking refs after a push
• Create lock files beneath the resolved worktree Git directory

The primary error is:

fatal: Unable to create 'C:/Dev/[repository]/.git/worktrees/[worktree]/index.lock': Permission denied

There is no stale index.lock.

Both an ordinary and an approval/elevation-assisted git add attempt from the Codex backend failed on the same path.

The identical staging and commit commands succeed immediately when run from regular, non-administrator PowerShell.

Effective identity split

The autonomous Codex backend runs under a dedicated Windows sandbox identity such as:

[machine]\CodexSandboxOnline

Ordinary PowerShell runs as the normal Windows user.

The normal user owns or controls the repository metadata and can create index.lock. The sandbox identity cannot.

ACL inspection shows explicit DENY entries affecting sandbox-created identities on the repository .git hierarchy or the resolved linked-worktree Git directory. Actual usernames, machine names, and SIDs are intentionally omitted.

The effective behavior is:

Ordinary PowerShell → normal Windows user → Git metadata write succeeds
Codex backend       → sandbox identity    → Git metadata write is denied

A project permission profile may declare .git writable, but an explicit Windows DENY ACE still wins.

Reproduction steps

1. Use Codex Desktop natively on Windows 11.

2. Configure:

   sandbox_mode = "workspace-write"
   
   [windows]
   sandbox = "elevated"
   

3. Open a trusted Git repository outside USERPROFILE.

4. Create or use a linked Git worktree.

5. Confirm that its .git pointer resolves to:

   [main repository]\.git\worktrees\[worktree]
   

6. Ask Codex to modify a tracked file.

7. From the autonomous Codex backend, run:

   git add [changed-file]
   

8. Observe:

   fatal: Unable to create '.../.git/worktrees/[worktree]/index.lock': Permission denied
   

9. Confirm that no stale lock exists.

10. Run the identical git add and git commit commands from ordinary, non-administrator PowerShell.

11. Observe that they succeed.

12. Inspect the Git metadata ACLs and observe explicit deny entries associated with sandbox identities.

13. Restarting Codex or continuing in later turns does not make the affected linked worktree writable.

Remote push half-success

Once a commit is created outside Codex, the Codex backend can push it successfully to GitHub. However, Git can then fail when updating the local remote-tracking ref because it cannot create the corresponding lock file beneath .git.

Observed result:

• Remote branch advances successfully
• Local origin/[branch] tracking ref remains stale
• Git reports a local ref-lock failure
• The task may incorrectly treat the push as failed or retry it

This is the same hazardous split-state behavior documented in issue #21869.

Impact

This breaks autonomous local PR workflows.

The repeated sequence becomes:

1. Codex implements and validates a change.
2. Codex cannot stage or commit it.
3. The task stops and asks the user to run a PowerShell command.
4. The user creates the commit manually.
5. Codex detects and pushes the commit.
6. CI or review discovers another necessary change.
7. The same manual checkpoint is required again.

A single PR required repeated user-operated staging and commit commands because each CI or review fix encountered the same unchanged Git ACL boundary.

The manual commit does not repair the ACL, so the failure repeats for every subsequent change.

This also makes long autonomous tasks misleading: editing and validation appear fully functional until the first checkpoint requiring a Git metadata write.

Relevant upstream implementation history

Several merged changes appear directly relevant.

Elevated Windows sandbox deliberately protects .git

PR #17365 — Include legacy deny paths in elevated Windows sandbox setup states that elevated setup and refresh include existing .git, .codex, and .agents directories in the deny-write set.

Its validation explicitly confirms the intended result:

• Attempting to modify .git/config produces Access is denied
• A DENY ACE is present on .git
• The same protection applies to elevated and unelevated Windows sandboxes

This establishes that denying .git writes is deliberate in the underlying sandbox implementation.

Persistent ACL reconciliation

PR #22569 — Simplify legacy Windows sandbox ACL persistence states that workspace-write already uses persistent ACL behavior and moves legacy handling toward persistent reconciliation rather than post-command cleanup.

This appears relevant to deny entries surviving across commands and sessions.

July ACL refresh behavior

PR #31138 — Allow deletion in writable roots, merged on July 8, changes Windows writable-root ACL handling and refreshes stale write ACEs.

It explicitly preserves .git as a protected child and adds regression coverage ensuring it remains protected.

This PR did not originally introduce .git protection, but it may be relevant to a newer Desktop build beginning to refresh or enforce previously stale ACL state consistently.

The exact mapping between this source change and Desktop package 26.707.6957.0 is not publicly confirmed.

Existing issue relationship

This likely shares an underlying policy or implementation boundary with:

• #18918 — Windows sandbox DENY ACLs break Git commits
• Maintainer comment stating that workspace-write does not allow writes to .git
• #18918 comment documenting the Windows Desktop identity split and danger-full-access workaround
• #27418 — Linked-worktree gitdir remains read-only despite explicit .git write permission
• #21869 — Remote push succeeds before local tracking-ref update fails
• #32872 — Windows sandbox materializes/protects .git in a non-Git workspace

This report is narrower than #32872 because the affected workspace is a real Git repository.

It adds information not present in the original #18918 report:

• Exact Codex Desktop package transitions
• A previously functional autonomous workflow immediately preceding the transition
• A repository outside USERPROFILE
• A linked worktree whose resolved Git directory is beneath .git/worktrees
• Explicit project permission granting .git write access
• Repeated manual checkpoint impact across one PR
• The remote-push/local-tracking-ref split state

Expected behavior

A trusted, explicitly writable repository should have a supported way to perform normal Git operations without disabling the entire sandbox.

Acceptable designs could include any of the following:

1. Allow Git metadata writes for the current trusted repository when explicitly authorized.

2. Honor a project permission profile that explicitly grants write access to the repository .git directory.

3. Correctly resolve linked-worktree .git pointer files and permit the required path under:

   [repository]\.git\worktrees\[worktree]
   

4. Broker a narrow set of Git metadata operations outside the file sandbox after normal approval, without giving arbitrary commands unrestricted filesystem access.

5. Detect Git commands requiring protected metadata and request an appropriate escalation before executing them.

6. Prevent git push from performing a remote side effect when the required local tracking-ref update cannot succeed.

7. At minimum, document clearly that workspace-write cannot stage, commit, fetch, or update refs, rather than allowing an autonomous PR workflow to fail only at checkpoint time.

Security boundary

I am not requesting unrestricted access to every .git directory on the machine.

The requested behavior is a narrowly scoped and auditable Git-write mechanism for:

• The currently trusted repository
• The active linked worktree
• Explicitly approved Git operations
• Explicitly configured project permission profiles

The currently suggested workaround, sandbox_mode = "danger-full-access", removes the sandbox’s filesystem and network boundaries. That is a disproportionate requirement merely to allow staging and committing inside one trusted repository.

OpenAI’s configuration guidance describes danger-full-access as running without sandbox restrictions and recommends caution:

• Official Codex configuration guidance

Requested investigation

Please confirm:

1. Which Codex Desktop package first included the current .git ACL reconciliation behavior.

2. Whether 26.707.6957.0 introduced or activated a change affecting elevated Windows workspace-write Git operations.

3. Whether a Desktop package update can refresh persistent ACLs for a repository or linked worktree that was already open.

4. Whether linked-worktree Git directories are intentionally denied even when their parent .git path is explicitly configured as writable.

5. Whether the intended product position is that workspace-write cannot perform autonomous staging, commits, fetches, or local ref updates.

6. Whether a supported narrow Git-operation broker or repository-scoped exception is planned.

Privacy and evidence handling

The following have intentionally been redacted:

• Windows username
• Machine name
• Sandbox SIDs
• Repository name
• Repository remote
• Branch name
• Commit hashes
• Private source paths beyond generic directory structure

No credentials, tokens, secrets, private keys, production data, or private repository contents are included.

I can provide additional sanitized AppX deployment events and ACL output if maintainers request them.

What steps can reproduce the bug?

1. Run Codex Desktop natively on Windows 11.

2. Configure Codex with:

   • sandbox_mode = "workspace-write"
   • [windows] sandbox = "elevated"

3. Open a trusted Git repository outside USERPROFILE.

4. Create or use a linked Git worktree whose .git file resolves to:

   C:\Dev\[repository]\.git\worktrees\[worktree]

5. Ask the autonomous Codex backend to modify a tracked file.

6. From the Codex task, run:

   git add [changed-file]

7. Git fails with:

   fatal: Unable to create '.../.git/worktrees/[worktree]/index.lock': Permission denied

8. Confirm that no stale index.lock exists.

9. Run the identical git add and git commit commands in ordinary, non-administrator PowerShell.

10. Observe that both commands succeed immediately.

11. Inspect the Git metadata ACLs and observe explicit DENY entries affecting Codex sandbox identities.

The failure repeats for every later CI or review fix because manually creating one commit does not repair the Git-directory ACL.

A push can also update the remote branch successfully and then fail to update the local remote-tracking ref because Codex cannot create its lock file beneath .git.

What is the expected behavior?

A trusted repository should have a supported, narrowly scoped way to perform normal Git operations without requiring danger-full-access.

When the repository or its .git directory is explicitly configured as writable, Codex should either:

1. Permit the Git metadata writes required for staging, commits, fetches, and local ref updates; or
2. Detect the protected Git operation and request a narrowly scoped escalation before executing it.

For linked worktrees, Codex must resolve the worktree’s .git pointer and handle the actual Git directory beneath:

[repository]\.git\worktrees\[worktree]

Codex should not allow a push to modify the remote branch and then leave the local tracking ref stale because the corresponding local lock file is denied.

Sandbox ACL entries should not persist or accumulate in a way that forces the user to perform every Git checkpoint manually.

The user should not need to disable all filesystem and network sandbox boundaries merely to stage and commit changes inside one explicitly trusted repository.

Additional information

No response

[olinkluzz1v]

Additional diagnostic evidence

I completed a strict preflight after the original report.

Environment:

• Windows 11
• Codex Desktop 26.707.8479.0
• dedicated CodexSandboxOnline execution identity
• custom repository permission profile extending the workspace profile
• the custom profile explicitly requests write access to the repository root and .git

Confirmed findings:

1. The repository’s .git directory contained four explicit DENY ACEs belonging to two sandbox-related SID families.
2. Those entries were inherited by Git metadata such as FETCH_HEAD, the index, and linked-worktree metadata.
3. Git commands failed inside Codex with Permission denied, while the same operations succeeded under the normal interactive Windows account.
4. I narrowly removed only those four explicit deny entries from <repository>\.git, preserving all other ACL entries.
5. After that repair, Codex successfully:
   • updated FETCH_HEAD;
   • refreshed and rewrote the Git index;
   • created, verified, and deleted a temporary Git ref;
   • created a fresh linked worktree;
   • left no stale lock files or temporary refs;
   • completed a non-mutating push dry run.

This strongly supports the explicit .git deny ACLs as the immediate cause of the Git failures.

I cannot determine conclusively which Codex Desktop update or sandbox ACL-reconciliation event introduced or preserved those entries. The custom profile itself did not request them; it explicitly requested .git write access.

A secondary issue appeared after ACL access was restored: Git HTTPS using Windows Schannel failed under the sandbox identity with SEC_E_NO_CREDENTIALS. A repository-local http.sslBackend=openssl setting restored Git transport. This may be separate from the ACL regression.

Separately, the WindowsApps-backed --codex-run-as-apply-patch helper later returned Access is denied. An approved out-of-sandbox attempt still failed, while restarting Codex Desktop restored the ordinary built-in patch helper. This appears to be a separate transient AppX execution-context issue.

No global ACLs, global Codex configuration, secrets, or repository content were changed during diagnosis.

[olinkluzz1v]

Recurrence on a fresh task after a confirmed successful repair

This issue has now reproduced again after the earlier ACL repair was proven successful.

Sequence:

1. The earlier repair removed four explicit DENY ACEs belonging to two sandbox-related SID families from the repository’s parent .git directory.

2. A strict preflight then passed: Codex could refresh the index, create and remove refs, fetch, create a fresh linked worktree, and authenticate the publication path.

3. Codex subsequently completed the full PR workflow successfully.

4. When I started the next fresh task against the same repository and permission profile, the problem returned before any implementation began.

5. The new task fetched the latest base and created its linked worktree, but this required proof failed:

   git update-index --refresh
   
   fatal: Unable to create 'C:/Dev/[repository]/.git/worktrees/[worktree]/index.lock': Permission denied
   

There was no stale lock, temporary ref, dirty worktree, or product change.

Read-only ACL inspection found:

• two explicit DENY ACEs had appeared again on the parent <repository>\.git;
• both were associated with one sandbox-related SID;
• both were inherited by .git\worktrees\[worktree];
• the visible linked-worktree directory itself contained no corresponding deny entries;
• the active managed permission profile explicitly listed both the repository root and .git as writable.

The SID could not be translated to a current Windows account name. This may indicate an ephemeral or retired sandbox principal.

The most important new signal is that the previous repair was not merely assumed to work: Git metadata writes passed and an entire subsequent PR workflow completed. Nevertheless, a fresh task later found explicit deny entries on the parent .git again.

This makes a one-time stale-ACL explanation less likely. It suggests that a new-task, sandbox-identity, or permission-profile initialization/reconciliation path may be recreating the protected .git deny entries. I cannot prove which internal component performs that reconciliation, but Git itself does not create Windows deny ACEs.

Approved recovery path also failed inside Codex

I explicitly approved a narrowly scoped repair that would remove only the two identified deny entries while preserving every other ACL entry.

Codex attempted to launch both PowerShell 7 and Windows PowerShell through its approved elevated execution path. Both elevated child processes failed to initialize with:

0xc0000142

The ACL repair never executed and the DACL remained byte-for-byte unchanged.

I therefore had to open an external Administrator PowerShell session manually. Because the SID was unresolved, an icacls /remove:d attempt returned Windows error 1332 (No mapping between account names and security IDs). Removing the two exact FileSystemAccessRule objects directly through the .NET ACL API succeeded.

Post-repair verification reported:

ACL_REPAIR=PASS removed=2 root_remaining=0 child_remaining=0

No broad ACL rewrite, global security change, sandbox disablement, alternate Git index, or repository-content workaround was used.

User and usage impact

This is extremely frustrating and is consuming my Codex usage allowance without advancing the requested work.

Every fresh task now risks spending approximately 7–10 minutes and many model/tool turns:

1. reading project instructions;
2. fetching and creating a worktree;
3. rediscovering the same index.lock failure;
4. collecting identity and ACL evidence;
5. stopping before implementation;
6. requesting another manual OS-level repair;
7. rerunning the full preflight.

The task can consume substantial usage before making a single product change. I also have to monitor supposedly autonomous work, leave Codex, open an elevated shell, repair ACLs manually, return to the task, and prompt it again.

This defeats the purpose of Codex Desktop’s autonomous local workflow and makes starting every new task both costly and unreliable.

Please investigate:

1. What task/profile initialization path is recreating explicit .git deny ACEs after a confirmed successful repair?
2. Why does this happen even when the managed permission profile explicitly declares the repository and .git writable?
3. Are per-task sandbox SIDs being left unresolved while their persistent deny ACEs remain?
4. Why did the approved elevated execution path fail to initialize PowerShell with 0xc0000142?
5. Can Codex detect this contradiction before consuming several minutes of task usage?
6. Can a durable, repository-scoped Git metadata broker or explicit trusted-repository exception be provided?

At minimum, the product should not repeatedly consume user usage diagnosing a sandbox state that it created and cannot repair itself.

[olinkluzz1v]

Final local recovery and clarification

I have now completed a full cleanup and fresh-task verification. The environment is working again, including Git metadata writes, linked worktrees, Docker-backed tests, browser tests, and normal patch application.

I am leaving this issue open because this is a description of how I recovered my machine—not proof that the underlying Codex/Windows behavior is permanently fixed for everyone.

Was this caused by my configuration?

Partly, but not in the way I originally feared.

The custom permission profile I created did not create the explicit Windows DENY ACEs on .git, based on the evidence available. The profile explicitly requested write access to the repository and its Git metadata.

However, my custom profile did contribute to the overall difficulty:

• It duplicated and complicated configuration that Codex Desktop already manages.
• It made it harder to distinguish the effective runtime policy from the written configuration.
• It covered the primary repository but did not correctly account for a sibling directory used for linked worktrees.
• A later worktree rejection was caused by that missing sibling-path boundary, not by an effective .git ACL denial.
• Existing tasks retained their selected profile, so configuration changes were not reliably reflected until Codex Desktop was restarted and a fresh task was created.

Therefore, the original Git ACL failure was real, but not every later failure with similar symptoms had the same cause.

Important correction about the remaining ACL entries

During the final verification, some DENY entries were still visible on .git, but their SIDs did not match the current Codex sandbox identity, its groups, or the interactive Windows user.

This matters because the mere presence of a deny entry does not prove that it affects the current execution token.

The final process was:

1. Identify the SID associated with each deny rule.
2. Compare it with the current sandbox and interactive-user identities.
3. Treat only an effective matching deny rule as an ACL blocker.
4. Diagnose automatic-review path rejections separately from Windows ACL failures.

Earlier, when matching deny rules were actively blocking Git, I removed only the exact explicit deny rules responsible for the failure while preserving every other ACL entry. I did not reset the repository ACL, rewrite the complete DACL, disable the sandbox, or broadly grant permissions.

I would strongly discourage using icacls /reset, recursively replacing permissions, or removing every unfamiliar SID without first proving that it affects the current token.

Configuration cleanup

I removed the custom named permission profile and returned to Codex Desktop’s regular Custom (config.toml) option.

The final high-level configuration is:

• Approval policy: On request
• Sandbox: workspace-write
• Network access: enabled
• Full Access: disabled
• Routine Git, GitHub, Docker, test, and runner commands handled through narrowly scoped automatic-review rules
• Repository, Git metadata, package caches, runner helpers, and sibling worktree locations treated as separate explicit boundaries

After changing this configuration, I restarted Codex Desktop and verified it from a fresh task. Existing tasks should not be relied upon to reload a changed permission profile.

Linked-worktree boundary

One later failure was caused by the sibling worktree root being outside the configured repository boundary.

The primary checkout and sibling worktrees had to be modeled separately:

• <repository> for the primary checkout and its .git metadata
• <sibling-worktree-root> only for worktrees created from that repository
• Temporary refs/codex-env-verification/* refs
• Temporary codex/env-verification-* branches and worktrees
• Mandatory cleanup after verification

This was kept behind scoped automatic review rather than turning the sibling directory into an unrestricted writable root.

Once that boundary was corrected, Codex successfully:

• ran git update-index --refresh;
• fetched and updated FETCH_HEAD;
• created, verified, and deleted a temporary ref;
• created a fresh linked worktree and branch;
• confirmed the new worktree was clean;
• completed a publication dry run;
• removed the temporary worktree, branch, and ref;
• left no locks or temporary Git metadata behind.

Git HTTPS was a separate issue

After Git metadata access was restored, Windows Schannel failed under the sandbox identity with:

SEC_E_NO_CREDENTIALS

This was separate from the ACL problem.

For this repository only, the following setting restored Git HTTPS transport:

git config --local http.sslBackend openssl

I retained this repository-local setting because explicitly forcing Schannel still reproduced the credential error. I did not modify the global Git TLS configuration.

This workaround should only be considered when the exact Schannel failure is present; it is not a general ACL fix.

Patch-helper failure was also separate

The WindowsApps-backed patch helper temporarily returned Access is denied, including through an approved execution attempt.

Restarting Codex Desktop restored normal patch behavior. A fresh task then created and removed a probe file through the built-in patch mechanism successfully.

That transient AppX execution-context failure should not be diagnosed as a Git ACL failure.

Docker required no security weakening

Docker initially appeared inaccessible from one sandbox context. I did not:

• change Docker ACLs;
• add sandbox identities to docker-users;
• expose Docker over TCP;
• grant Full Access; or
• weaken system security.

After the configuration cleanup and fresh-task restart, a normal docker version call reached both the Docker client and server without an approval prompt. The project’s container-backed validation subsequently passed.

This suggests the earlier Docker failure was tied to the effective task/runtime context rather than requiring a permanent Docker security change.

Propagating local Codex settings to managed worktrees

The repository-local .codex configuration is intentionally ignored by Git. That meant a newly created Codex-managed worktree did not automatically have the local configuration and agent definitions.

I added a deliberately narrow, locally ignored .worktreeinclude containing only active files:

.codex/config.toml
.codex/agents/*.toml
.codex/environments/environment.toml
.codex/rules/workhub.rules

It intentionally excludes:

• .codex/inbox;
• configuration backups;
• attachments;
• analysis artifacts; and
• broad .codex/** copying.

A clean Codex-managed worktree was then created from the default branch. It received exactly the intended files, all TOML files parsed successfully, and the excluded paths were absent.

Final verification

The final environment passed all of the following:

• Git index and ref writes
• FETCH_HEAD updates
• Fresh linked-worktree creation and cleanup
• GitHub authentication and repository access
• Publication dry run
• Built-in patch application
• Docker client/server access
• Dependency restore and build
• Unit and integration validation
• Container-backed authentication/database lanes
• Critical browser automation
• Real Chrome-extension control
• Repository-local agent configuration in a clean Codex-managed worktree

No broad ACL reset, global security weakening, Docker permission change, alternate Git index, hidden checkout, remote/API commit workaround, or danger-full-access mode was used.

Current conclusion

My custom profile made the setup harder to reason about and caused one separate sibling-worktree boundary problem, so removing it was the correct decision.

However, it does not explain how the original explicit .git deny rules appeared, why matching deny rules previously returned after a successful repair, or why approved elevated PowerShell processes failed to initialize during one recovery attempt.

The local environment is now healthy, but I am leaving this issue open because Codex Desktop should still provide a durable and understandable repository-scoped mechanism for normal Git metadata operations. Users should not have to diagnose sandbox identities, persistent Windows ACL entries, path-policy boundaries, TLS backends, and AppX helper contexts merely to stage and commit changes in one trusted repository.

[olinkluzz1v]

I'm literally losing it right now :)

I lost power mid task, and somehow ACL and God knows what else got corrupted, although that shouldn't be the case. So here we go again. Spending more hours and more usage to stabilize the environment. smh...

[olinkluzz1v]

Second recurrence after a power interruption: full recovery details

This is a follow-up to my previous recovery report and my comment immediately after the power interruption.

The environment is working again, but recovering it required another lengthy investigation and manual intervention.

What failed

After losing power during an active task, every sandboxed Codex command began failing before the requested program could start:

{ "code": "helper_unknown_error", "message": "apply deny-read ACLs" }

This was broader than the original Git metadata problem:

• A minimal sandboxed whoami could not start.
• The built-in patch mechanism could not run.
• Normal repository work could not continue.
• Restarting Codex Desktop initially did not fix it.

At the same time:

• The repository itself was intact.
• Git and GitHub worked outside the failing sandbox context.
• The already-merged pull request remained healthy.
• The Windows sandbox accounts and group existed and were enabled.
• Docker Desktop and its Linux engine were healthy.
• No source code, credentials, or repository data had been corrupted.

How much user intervention was required

Counting command blocks—not every PowerShell statement inside each block—I had to run three manual PowerShell command blocks outside Codex:

1. A read-only command to inspect the existing sandbox setup error and filtered sandbox log.
2. An Administrator PowerShell recovery command that backed up and reprovisioned the three Codex sandbox-state directories.
3. A read-only post-reprovision command to inspect the new sandbox directory metadata and look for a current diagnostic log.

In addition, recovery required 11 separate narrowly scoped approval messages for ACL inspection, ACL cleanup, attachment access, sandbox-state metadata, account/package metadata, filtered logs, SQLite log inspection, reprovisioning, and final verification.

I am not counting Codex’s internal read-only probes and tool calls as manual commands, but there were many of those as well.

Investigation and recovery timeline

1. I ruled out repository and CI corruption

The task running when power was lost involved a real but unrelated PostgreSQL test-cleanup race. The concurrent Accounting security task was read-only and was not running builds, tests, or Docker.

Neither task explained why a minimal sandboxed whoami could not start. The Codex environment failure was therefore diagnosed separately from the repository test failure.

2. I backed up and inspected the WorkHub ACLs

Before changing any ACL, the existing descriptors were saved under a Git-ignored recovery directory.

The WorkHub task root contained orphaned entries from deleted sandbox identities:

• 12 explicit orphaned Deny rules across the protected .git, .codex, and .agents directories.
• Four additional orphaned Allow rules.

Those exact entries were removed while preserving ownership and every unrelated ACL entry.

A narrow explicit Modify rule for the existing sandbox group was tested. It did not restore sandbox startup, so that ineffective permission change was rolled back. Only the confirmed orphan cleanup was retained.

No recursive ACL reset, ownership rewrite, or broad permission grant was used.

3. The first successful patch probe exposed a deeper problem

After the initial cleanup, one built-in patch operation succeeded, but the next operation failed again during sandbox setup.

That showed that the old ACL residue was real, but removing it was not a complete or durable fix. The current Codex helper was still unable to initialize consistently.

4. Restarting Codex did not repair it

I fully exited and reopened Codex Desktop. The first minimal whoami probe still failed before launch.

This ruled out a single stuck helper process.

5. A second writable root contained more orphaned ACL state

The task had two writable roots:

• The WorkHub repository.
• A task-specific Codex visualization directory.

The second root contained one deleted sandbox SID with seven stale rules:

• One explicit Allow rule on the root.
• Two explicit Deny rules on each of .git, .codex, and .agents.

Those seven rules were backed up and removed narrowly.

Afterward, both writable roots were canonical and contained no remaining rules for those orphaned identities. Nevertheless, sandbox startup still failed.

This proved that orphaned workspace ACLs were contributing residue, but they were not the entire root cause.

6. Persisted sandbox state was inconsistent with the installed app

The next inspection found a significant state mismatch:

• The current setup_error.json was created at the new failure time.
• Other sandbox marker, log, and user-state files dated back to May 28.
• The installed Codex Desktop package was 26.707.9981.0.
• The cached command runner was 0.144.2.
• Both CodexSandboxOnline and CodexSandboxOffline existed, were enabled, and belonged to the expected sandbox group.

The account objects were healthy, so recreating Windows users or changing group membership would have been the wrong repair.

The evidence instead pointed to stale or internally inconsistent persisted sandbox provisioning state. Similar setup-state recovery has been discussed in issue #18620, while stale setup_error.json behavior has also been reported in issue #25296.

7. The available logs did not expose the real helper error

Filtered Codex Desktop logs and a read-only query of logs_2.sqlite contained only the final router-level error.

They did not contain:

• The exact filesystem path being processed.
• The SID or principal involved.
• The underlying Win32 error.
• The sandbox helper’s stderr.

This generic error reporting was a major reason the diagnosis took so long.

8. I backed up and reprovisioned Codex’s sandbox state

The following three directories were renamed to timestamped backups:

<CODEX_HOME>\.sandbox
<CODEX_HOME>\.sandbox-secrets
<CODEX_HOME>\.sandbox-bin

Nothing was deleted.

A bundled Codex CLI command then triggered fresh sandbox provisioning using a read-only whoami probe.

The standalone command reported:

windows sandbox failed: helper_unknown_error: setup refresh had errors

However, all three replacement directories were created successfully at the same timestamp. After reopening Codex, a normal sandbox invocation succeeded.

9. Final verification

The repaired environment successfully completed:

• A sandboxed whoami under the current CodexSandboxOnline identity.
• A built-in apply_patch operation.
• Git index and commit operations.
• Branch push and pull-request creation.
• Docker client/server verification with approved host access.
• Three focused unit tests.
• One complete Docker/Testcontainers/PostgreSQL test lifecycle.
• PostgreSQL database creation, migrations, validation, and teardown.
• Container-residue inspection with no new WorkHub/Testcontainers residue.

No Docker ACLs, Windows account membership, global Git TLS settings, credentials, or broad operating-system security settings were changed.

The timestamped sandbox-state and ACL backups remain available for rollback.

Root-cause conclusion

The confirmed immediate failure was the Codex Windows sandbox setup helper aborting during apply deny-read ACLs before launching even a harmless command.

There were two contributing forms of stale local state:

1. Orphaned sandbox ACL entries existed on both writable roots.
2. Codex’s persisted sandbox provisioning state was substantially older than the installed Desktop/helper version.

Removing the orphaned ACL entries alone did not fix startup. Backing up and regenerating .sandbox, .sandbox-secrets, and .sandbox-bin restored both sandboxed command execution and the patch helper.

Therefore, the best-supported root cause is an inconsistent or stale persistent Windows sandbox state combined with orphaned sandbox ACL residue.

I cannot honestly prove that the power interruption created this state. It may have exposed or interrupted an already fragile refresh operation. I also cannot prove that two concurrent Codex tasks caused it. The read-only Accounting task was not directly responsible.

The exact upstream product defect remains unknown because the helper exposes only a generic error and does not persist the underlying path, principal, Win32 result, or stderr.

Product feedback

I want to phrase this constructively, but the recovery experience is not acceptable for a desktop development tool.

A power interruption or interrupted task should not leave the application unable to launch even whoami, and a user should not need to understand SIDs, ACL canonicality, sandbox users, AppX execution contexts, SQLite runtime logs, or internal sandbox-state directories merely to restore basic functionality.

At minimum, Codex Desktop should:

1. Display and persist the exact path, principal, ACL operation, and Win32 error that failed.
2. Make sandbox-state updates atomic and recoverable after abrupt process or system termination.
3. Detect stale or mismatched sandbox provisioning state automatically.
4. Provide an in-app, backup-first “Repair Windows sandbox” operation.
5. Serialize sandbox ACL reconciliation safely across concurrent tasks.
6. Distinguish workspace ACL failures from internal sandbox-state failures.
7. Verify the repair with a minimal probe and report clearly whether it actually succeeded.
8. Avoid requiring Administrator PowerShell for routine application recovery.
9. Continue pursuing a narrow, auditable mechanism for trusted-repository Git metadata writes without requiring danger-full-access.

The environment is operational again, but I am leaving this issue open. This is the second substantial recovery effort, and the current workaround is too complex and fragile to be considered a durable product-level resolution.