Codex Desktop on macOS: worktree creation can time out after Git succeeds, leaving orphaned worktrees with no thread/session state

Summary

On Codex Desktop for macOS, creating a new worktree-backed thread sometimes times out even though the underlying Git worktree creation already succeeded.

In the failed case I inspected locally, Git created a detached worktree under ~/.codex/worktrees/..., but Codex never created the corresponding thread/session state. That leaves an orphaned worktree behind and the UI behaves as if thread creation failed.

Environment

• Codex Desktop: 26.325.31654 (build 1272)
• macOS: 26.2 (Darwin 25.2.0, arm64)
• Local repo on macOS filesystem (not WSL)
• GitHub auth is unrelated here; this reproduces before any repo/network workflow

What I measured locally

A raw Git control check is fast:

git worktree add --detach <tmp> HEAD   -> 2.493s
remove test worktree                   -> 0.845s

So the user-visible timeout does not appear to be caused by git worktree add itself.

Strongest failing symptom

I had a failed create attempt that produced a real Git worktree here:

~/.codex/worktrees/3873/s3nergy2

It was visible in git worktree list as a detached worktree, but there was no matching Codex state:

• no threads row in ~/.codex/state_5.sqlite
• no matching entry in ~/.codex/session_index.jsonl
• no rollout/session file for that cwd under ~/.codex/sessions/...

So Git-side creation succeeded, but desktop bootstrap did not finish and did not roll back the created worktree.

Timing evidence from successful thread creations

Looking at rollout timestamps, the gap between the recorded thread/session metadata timestamp and the first actual rollout event varies a lot:

• 2026-04-02 12:30:38 local thread 5127: 19.881s
• 2026-04-02 12:47:51 local thread 5f0e: 20.140s
• 2026-04-03 13:44:10 local thread 3cde: 5.511s
• 2026-04-06 12:01:42 local thread 7a53: 0.854s

That makes it look like the unstable part is the Desktop bootstrap after Git succeeds, not the Git operation itself.

Expected

If worktree creation succeeds, Codex should either:

1. finish creating the thread/session state reliably, or
2. cleanly roll back and remove the just-created worktree if bootstrap fails.

Also, it would help if the UI reported which stage timed out instead of showing it all as a generic worktree-creation failure.

Actual

• UI sometimes hangs / times out during "creating worktree"
• Git worktree may already exist at that point
• Codex may fail before writing thread/session state
• orphaned worktrees can be left behind and require manual cleanup

Possibly related

• #12491
• #14470
• #4726
• #13618

Notes

I also found lingering shells with cwd inside old worktrees and cleaned them up, but that does not explain the core issue because raw Git worktree creation remained fast. The more convincing signal is the partially successful create: Git worktree present, but no Codex thread/session state.