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

[gritsev]

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

• Codex.app GUI: MCP child processes not reaped after task completion — 1300+ zombies, 37GB memory leak #12491
• codex exec --json resume can hang indefinitely on macOS after MCP helpers start #14470
• Missing child.wait() after start_kill() creates zombie processes and prevents directory cleanup #4726
• Codex App worktree creation fails for WSL-backed repos with "Failed to resolve worktree git directory" #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.

[github-actions]

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

• Codex app on Windows + WSL: automation shows no Local option, fails with "no rollout found for thread", and leaves orphaned worktrees #15854
• Codex can print a session ID but fail to persist any resumable local session artifacts after early transport failure #15870
• app-server websocket shared-thread turns complete but rollout never materializes, so sibling thread/resume fails with "no rollout found" #16872

Powered by Codex Action

[gritsev]

I reviewed the suggested duplicates.

Closest match is #15854, but that one is specifically Windows + WSL + automation flow and includes the missing Local option / no rollout found for thread behavior there.

This issue is narrower and different in two important ways:

• it reproduces on macOS Desktop with a normal worktree-backed thread create on a local repo (not WSL, not automation-specific)
• the strongest local symptom is a partially successful create where Git already created the detached worktree, but Codex never persisted any matching thread/session/rollout state for that cwd

The other two look related at the persistence/materialization layer but not as direct duplicates:

• Codex can print a session ID but fail to persist any resumable local session artifacts after early transport failure #15870 is CLI early transport failure without persisted session artifacts
• app-server websocket shared-thread turns complete but rollout never materializes, so sibling thread/resume fails with "no rollout found" #16872 is shared app-server websocket rollout materialization failing after a completed turn

So I think these are related reports in the same failure family, but not exact duplicates of this Desktop/macOS worktree-bootstrap case.