Codex Desktop managed worktree creation reports AGENTS.override.md failure even though git worktree add succeeds and no ls-files command is spawned

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

• #28381

Powered by Codex Action

I captured a success and failure with GIT_TRACE2 enabled.

Success:

• git worktree add for .../.codex/worktrees/9326/n2 exited 0 after 7.91s
• Codex then ran:

git ... ls-files --others --ignored --exclude-standard -z -- :(glob)**/AGENTS.override.md

• that command exited 0 after 2.15s
• app log then emitted [worktree-create] ready and owner-thread-set
• the worktree git admin dir has codex-thread.json and config.worktree

Failure:

• git worktree add for .../.codex/worktrees/1421/n2 exited 0 after 8.52s
• no AGENTS.override ls-files command was spawned
• app log never emitted [worktree-create] ready or owner-thread-set
• the worktree remains registered in Git, but its admin dir lacks

codex-thread.json and config.worktree

So the bug appears to be that the Desktop post-create continuation is getting
lost/cancelled after successful checkout and before the AGENTS.override scan.
The UI reports "git ls-files failed while locating AGENTS.override.md", but in
the failed trace that git command was never invoked.

Update: root cause narrowed down and workaround confirmed

I reproduced this again with Codex Desktop 26.623.101652 (build 4674, codex-cli 0.142.5), and now have a controlled A/B that makes worktree creation succeed without changing the Git binary.

Codex Desktop does the following:

1. It loads my interactive shell environment using zsh -ilc with CODEX_SHELL=1, then merges that environment into process.env. This explained why launching Codex with a custom PATH did not initially change the result.
2. Its Git availability check finds the first executable named git in PATH.
3. On macOS, when that path is exactly /usr/bin/git, it runs:

/usr/bin/xcode-select -p

synchronously with a one-second timeout.

1. The availability result is cached for ten seconds.
2. After git worktree add succeeds, Codex unconditionally runs the ignored AGENTS.override.md scan. Because this repository takes roughly 7-14 seconds to check out, that scan can require a fresh availability check.
3. If the availability check fails, Codex returnsGit is unavailable before spawning git ls-files. The caller discards that underlying error and reports:

git ls-files failed while locating AGENTS.override.md

This matches the original trace, in which git worktree add exited successfully but no git ls-files process was spawned.

The confirming A/B was:

Before:

$ command -v git
/usr/bin/git

Managed worktree creation repeatedly failed after checkout.

I then added an earlier PATH entry pointing to the same Git binary:

ln -s /usr/bin/git "$HOME/.local/bin/git"

$HOME/.local/bin was already before /usr/bin in my interactive
shell PATH. Afterward:

$ command -v git
/Users/.../.local/bin/git

$ git --version
git version 2.50.1 (Apple Git-155)

I did not restart Codex. The next managed-worktree creation succeeded, and the Desktop logs recorded both:

[worktree-create] ready
[worktree-create] owner-thread-set

Since the symlink executes the identical /usr/bin/git binary and only changes the path spelling seen by the availability check, this
strongly implicates the /usr/bin/git-specific preflight.

I have not determined why xcode-select -p intermittently fails inside the Git worker; it succeeds consistently when run manually. Desktop logs do, however, show bursts of Git is unavailable errors while Git continues to work normally outside the app.

Possible fixes:

• Do not repeat Git availability checking between steps of one successful worktree-creation operation.
• Treat worktree_pending_create and worktree_managed_create as availability-check bypass contexts after git worktree add has already succeeded.
• Retry the xcode-select probe or increase its one-second timeout.
• Preserve the underlying Git is unavailable or spawn error instead of replacing it with the AGENTS.override.md message.
• Roll back the newly created Git worktree when Desktop bootstrap fails, rather than leaving an orphan.

The orphaned-worktree symptom may be related to #16936, although this issue now has a more specific reproduction and workaround.