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

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.

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.

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.

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...

<img width="1065" height="881" alt="Image" src="https://github.com/user-attachments/assets/4e644596-8b19-407b-a5d7-286406f410c4" />

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.

Corroboration from another current Windows 11 installation (2026-08-10).

Environment:

• Codex CLI 0.146.0
• native Windows sandbox, workspace-write
• dedicated execution identity: CodexSandboxOnline
• linked Git worktree

Observed:

• ordinary worktree files are writable;
• Git metadata is readable;
• git add cannot create .git/worktrees/<worktree>/index.lock: Permission denied;
• the identical repository operation succeeds under the normal user/another local agent;
• a standalone command explicitly approved for host escalation still reports CodexSandboxOnline, so the approval path does not cross to the host identity;
• the working tree remains safe, but every commit requires another actor.

This reproduces the effective-DENY/worktree-metadata split described here. A one-time ACL edit is not an acceptable fix because sandbox reconciliation can recreate the denial.

Please provide a supported solution that preserves the sandbox: either grant the resolved common Git metadata directory the narrowly required Git operations for an authorized linked worktree, or broker staging/commit/ref updates outside the sandbox.

Additional reproduction on a normal Git working tree (not a linked worktree), with a newer Codex Desktop build and a precise activation boundary.

Environment

• Windows 11 x64
• Codex Desktop package update: 26.810.6296.0 → 26.810.7004.0
• Bundled Codex CLI after restart: 0.148.0-alpha.9
• sandbox_mode = "workspace-write"
• [windows] sandbox = "elevated"
• Normal Git repository under a local development directory
• No stale .git/index.lock

Activation timeline

Windows AppX deployment events show that package 26.810.7004.0 was installed at approximately 2026-08-15 20:16 local time. The older Desktop process remained running after installation.

Under that still-running process, the same Codex task successfully completed seven local commit/push workflows on 2026-08-15, including a successful push at approximately 23:13.

Codex Desktop was fully restarted on 2026-08-16 at approximately 11:27. The new package and bundled CLI became active at that point. After the restart, Git metadata writes began failing consistently:

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

Ordinary workspace file edits still succeed. No Git lock file exists.

Important configuration evidence

The Windows sandbox setting did not change at the failure boundary. Available configuration backups show sandbox = "elevated" had already been in use for weeks, including while the successful commit/push workflows above were working.

The managed permission requirements also predate the regression. This makes a local configuration change an unlikely trigger and instead points to behavior activated by the new Desktop/CLI process after restart.

Approval/escalation behavior

A Git write attempted through the approval/escalation path also fails. The resulting command still runs as the dedicated offline sandbox identity rather than transitioning to an identity that can write the trusted repository's Git metadata.

In this reproduction, both the ordinary attempt and the approval-assisted attempt fail at the same .git/index.lock boundary.

Why this adds to the existing report

• Reproduces on a normal repository, not only linked worktrees.
• Provides a successful-before / failed-after boundary within the same task and repository.
• Separates package installation time from the time the new package became active after Desktop restart.
• Shows the elevated configuration itself was not newly introduced.
• Shows the approval path does not provide a narrow Git metadata write path.

This appears to be a regression in the Desktop Windows sandbox/approval execution path activated by package 26.810.7004.0 / bundled CLI 0.148.0-alpha.9, rather than a stale Git lock or repository-specific failure.

Requested behavior remains a narrowly scoped, auditable way for an approved Git operation to update metadata in the current trusted repository without requiring a permanent switch to the weaker unelevated sandbox or disabling sandbox boundaries.