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

Activity

1. olinkluzz1v

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 13, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Jul 13, 2026
3. olinkluzz1v commented on Jul 14, 2026

   

   olinkluzz1v

   on Jul 14, 2026

   Author

   More actions

   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.
4. olinkluzz1v commented on Jul 14, 2026

   

   olinkluzz1v

   on Jul 14, 2026

   Author

   More actions

   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.
5. olinkluzz1v commented on Jul 15, 2026

   

   olinkluzz1v

   on Jul 15, 2026

   Author

   More actions

   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.
6. olinkluzz1v commented on Jul 15, 2026

   

   olinkluzz1v

   on Jul 15, 2026

   Last edited by olinkluzz1v

   Author

   More actions

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

   

   🎉React with 🎉1Reacted by olinkluzz1v
7. olinkluzz1v commented on Jul 15, 2026

   

   olinkluzz1v

   on Jul 15, 2026

   Author

   More actions

   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.
8. VerityCE commented on Aug 10, 2026

   

   VerityCE

   on Aug 10, 2026 – with ChatGPT Codex Connector

   More actions

   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.
9. Yuuu54 commented on Aug 16, 2026

   

   Yuuu54

   on Aug 16, 2026 – with ChatGPT Codex Connector

   More actions

   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.
10. wildzerotypes-gif commented on Sep 8, 2026

    

    wildzerotypes-gif

    on Sep 8, 2026

    More actions

    Additional related reproduction with Codex CLI 0.146.0 on native Windows, including an explicit permission profile and a fresh sandbox invocation after the official setup command. This is an existing ordinary repository with a .git directory, not a linked worktree. I have not established the same Desktop update regression timeline as the original report.

    Configuration

    The legacy sandbox_mode and [sandbox_workspace_write] settings were removed before selecting this profile. The path below is a placeholder for the actual absolute repository path:

    default_permissions = "workspace-git"
    
    [windows]
    sandbox = "unelevated"
    
    [permissions.workspace-git]
    extends = ":workspace"
    
    [permissions.workspace-git.filesystem]
    "C:/path/to/repository/.git" = "write"
    
    [permissions.workspace-git.network]
    enabled = true

    Observations

    1. The Desktop task's supplied effective filesystem permissions listed the actual repository .git path as writable. CLI configuration loading also succeeded.

    2. Sandboxed fetch still failed with:

       error: cannot open '.git/FETCH_HEAD': Permission denied
       

    3. Read-only ACL inspection found explicit write-deny ACEs on .git, inherited by FETCH_HEAD. A SID returned by GetTokenInformation(TokenRestrictedSids) in the failing execution context matched one of those deny ACEs. An allow ACE for that SID was also present. The actual SID values are omitted here.

    4. The official interactive CLI command /setup-default-sandbox returned Sandbox ready and changed [windows].sandbox to elevated.

    5. To distinguish an existing Desktop execution context from a newly initialized sandbox, the following was launched from outside the agent sandbox after setup:

       codex sandbox -P workspace-git -- git fetch
       

       It also exited with status 1 and the same FETCH_HEAD: Permission denied error. This is evidence from a new CLI sandbox invocation; it does not establish that the existing Desktop task switched to the new Windows sandbox implementation.

    Earlier approval-based execution outside the sandbox allowed git pull --ff-only to succeed. No ACLs were manually removed, and no full-access mode was enabled. Git for Windows version reported by diagnostics was 2.53.0.windows.1. Desktop application version and exact Windows build were not collected.

    Requested clarification

    Is an explicit .git write override in a profile extending :workspace supported on native Windows? If so, how should existing protected-path deny ACEs be reconciled when the profile changes? If it is unsupported, a validation error or an effective-policy warning would be clearer than reporting the path writable while Git is still denied by Windows.

    The observed ACL/token match establishes a local access-control conflict, but does not establish which Codex component originally created the deny ACE or whether its persistence is the underlying implementation defect.

    No full configuration, credentials, repository contents, machine names, actual local paths, SID values, or session logs are attached.
11. PouriaMzn commented on Sep 26, 2026

    

    PouriaMzn

    on Sep 26, 2026

    More actions

    Additional narrowing: exact resolved worktree gitdir write rule works

    I found a reproducible distinction that may help narrow this issue.

    Environment:

    • Native Windows Codex Desktop v26.908
    • [windows] sandbox = "elevated"
    • Managed permission profile
    • Codex-created linked worktree
    • Paths below sanitized

    My effective profile explicitly allowed:

    '<repo>\.git' = "write"
    '<repo>\.git\worktrees' = "write"

    The session metadata confirmed both entries were active.

    However, the worktree's .git pointer resolved to:

    <repo>\.git\worktrees\<generated-worktree>
    

    and the sandbox log showed:

    granting write ACE to <repo>\.git\worktrees
    ...
    applied deny ACE to protect <repo>\.git\worktrees\<generated-worktree>
    

    A direct write to the resolved gitdir failed with Access denied.

    I then added an explicit rule for that exact resolved path:

    '<repo>\.git\worktrees\<generated-worktree>' = "write"

    After clearing the existing DENY ACL on that test directory and reopening the same worktree:

    • creating/deleting a probe file inside the resolved gitdir succeeded;
    • git update-index --refresh succeeded;
    • normal git status remained fine.

    This appears consistent with current codex-rs/protocol/src/permissions.rs, where automatic resolved-gitdir protection is suppressed only when has_explicit_resolved_path_entry(...) finds an entry whose path exactly equals the resolved gitdir.

    So in my reproduction:

    parent .git/worktrees WRITE    -> resolved child still protected
    exact resolved gitdir WRITE    -> Git metadata writes succeed
    

    The workaround is not durable because Codex generates the worktree metadata directory name dynamically, so the exact path changes between worktrees.

    This may be useful when investigating whether an explicitly writable ancestor should count as authorization for the resolved gitdir, or whether linked worktrees need a first-class repository-scoped exception.
12. PouriaMzn commented on Sep 27, 2026

    

    PouriaMzn

    on Sep 27, 2026

    More actions

    Follow-up: filesystem deny rules appear to trigger the failure

    I did additional A/B testing after my previous comment and narrowed this further.

    On the same native Windows / elevated-sandbox setup, a custom profile with workspace access and a network allowlist works normally with Codex-created linked worktrees.

    When Git needs to modify protected metadata, Codex prompts to run the operation outside the sandbox. After approval, branch creation, git add, and git commit succeed.

    The behavior changes as soon as I add a filesystem deny rule.

    For example, this single rule is sufficient to reproduce it:

    [permissions.project-edit.filesystem.":workspace_roots"]
    ".env" = "deny"

    I also reproduced the same problem with other deny patterns, including rules targeting nested .env files and secret files. So .env itself does not appear special; it is simply the smallest reproducer I tested.

    With a filesystem deny active, linked-worktree Git operations fail with errors such as:

    Unable to create '<repo>/.git/worktrees/<worktree>/index.lock': Permission denied
    

    and, for branch creation:

    cannot lock ref 'refs/heads/<branch>'
    

    A notable part of the behavior is that the approval flow can still occur: Codex may detect that Git needs additional access and prompt the user to run the operation outside the sandbox. However, after the user approves the escalation, the Git operation can still fail because it cannot create the linked-worktree metadata file/ref.

    Removing the filesystem deny entries restores the previous behavior: Codex prompts for escalation when needed, the user approves it, and the Git operation succeeds.

    I reproduced the deny-triggered failure both when the rule was defined globally and when it was added through repository-level .codex/config.toml, so the config layer does not appear to be the determining factor.

    I also tested the host-context Git workaround discussed in #18918 / #37965:

    • Git prompt rules in .codex/rules did not resolve the failure.
    • An AGENTS.md instruction explicitly telling Codex to run Git through the host-context/escalated path did not resolve it either.

    So in my reproduction, the significant boundary appears to be:

    No filesystem deny
    → Git requires escalation
    → user approves
    → Git metadata write succeeds
    
    Any tested filesystem deny
    → Git requires/requests escalation
    → user approves
    → linked-worktree metadata write can still fail with Access Denied
    

    This does not invalidate the exact-resolved-gitdir workaround from my previous comment, but it may help narrow which permission-policy feature activates the problematic Windows ACL behavior.