Fork from earlier turn into worktree stalls before creating child thread
Summary
In Codex Desktop, Fork from an earlier turn → New worktree can enter a pending-worktree state but never create either the worktree-backed child thread or the worktree directory.
This is a same-host failure. It has been observed when the source thread and requested worktree are both on the local host, and also when both are on the same connected remote host. Cross-host handoff is not part of the reproduction.
The failure is disproportionately associated with forking from an earlier completed turn. Forking the same source thread into the same directory succeeds immediately.
Environment
- Codex Desktop
- Observed with a remote app-server/CLI reporting
0.142.5 - Observed on both macOS local projects and Linux remote projects, with each attempt remaining on one host
- Source project is a Git repository
- No project
.codex/environments/**configuration is present
Steps to reproduce
- Open an existing Codex thread in a Git-backed project.
- Choose a completed earlier turn, not the latest turn.
- Select Fork into new worktree.
- Wait for worktree setup and child-thread creation.
Expected behavior
Codex creates a managed worktree and a child thread rooted in that worktree, or returns a visible actionable error.
Actual behavior
- The fork request returns/enters a pending-worktree state.
- No child thread becomes visible.
- No new managed worktree directory appears under
$CODEX_HOME/worktrees. - No persisted child-thread/worktree ownership record appears.
- Remote app-server logs show no worktree-provisioning request or Git worktree error for the pending fork.
- Forking the same source thread into the same directory succeeds immediately.
In one captured incident, the pending worktree remained unresolved for several minutes and never materialized; the same-directory fallback produced a child thread within seconds.
Diagnostics
- The app-server filesystem is writable; this is not explained by a read-only sandbox.
- The project has no local-environment setup file, and local environments are optional.
- The failure appears to happen in Desktop/client orchestration before the target host receives normal worktree provisioning.
- The symptom fits stale or missing source-conversation host ownership during the asynchronous earlier-turn fork path, especially when the source conversation is not currently loaded.
Suggested fix
- Preserve explicit source host selection through the full fork from earlier turn → pending worktree → child conversation flow.
- Add regression coverage for an earlier-turn worktree fork when the source conversation is unloaded or belongs to a connected remote host.
- Surface a terminal error instead of leaving a pending worktree without a child thread.
Related issues
- #21432 covers worktree creation with the runtime cwd still pointing at the original checkout.
- #13146 covers worktree threads being attributed to the wrong project.
Those are adjacent symptoms, but this report is specifically about an earlier-turn worktree fork that never produces a child thread or worktree.