Codex Desktop creates a valid worktree, then shows “Failed to start the conversation” without sending thread/start

[f-trycua]

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.715.31925, bundled codex-cli 0.145.0-alpha.18.

What subscription do you have?

Not included; the failure occurs locally before a conversation-start request reaches the app server.

What platform is your computer?

macOS 26.5.2, Apple Silicon (arm64).

What issue are you seeing?

Creating a new worktree-backed conversation completes the Git worktree operation, but Codex Desktop immediately marks the conversation start as failed:

[info] Starting worktree creation
Preparing worktree (detached HEAD <sha>)
HEAD is now at <sha> <commit subject>
Worktree created at <CODEX_HOME>/worktrees/<id>/<repo>
No local environment selected

Failed to start the conversation

The resulting worktree is healthy: it is registered by Git, clean, detached at the requested commit, and usable from the command line. However, Codex creates no thread/session for it.

Retrying produces another valid detached worktree and the same frontend failure, leaving orphan worktrees behind.

Local diagnostics at the failure timestamp show:

• Git worktree creation completed successfully.
• The app-server/backend log contains no thread/start request for the attempted conversation.
• The local thread database and session storage contain no new thread or rollout for the attempt.
• No local environment selected is informational; no setup environment was selected, and worktree creation itself returned success.
• Desktop's global state had inconsistent project selection: selected-project referred to synthetic project A while active-workspace-roots and electron-saved-workspace-roots referred to synthetic project B.
• The pending worktree UI state changed from waiting/starting to failed before backend thread creation.

This appears to be a Desktop frontend/project-routing failure after successful worktree creation and before the app-server conversation-start RPC.

All repository names, local paths, commit identifiers, commit subjects, prompts, and account details have been intentionally omitted.

What steps can reproduce the bug?

This has reproduced twice in the affected state:

1. Have multiple saved local projects in Codex Desktop.
2. Reach a state where the selected project and active/saved workspace root are different (the mismatch was observed in local Desktop state; the exact UI sequence that produced it is not yet known).
3. From the intended project, submit a prompt using Worktree with no local environment selected.
4. Wait for the worktree setup card to report that the detached worktree was created.
5. Observe Failed to start the conversation.
6. Inspect the result:
   • git worktree list --porcelain shows a valid worktree at the requested commit.
   • no corresponding thread/session was created;
   • no thread/start request appears in backend logs.
7. Click retry and observe a second valid orphan worktree followed by the same failure.

What is the expected behavior?

After Git successfully creates the worktree, Codex Desktop should start the conversation against that worktree and associate it with the project that initiated the request.

If project-routing state is inconsistent, Desktop should either reconcile it automatically or stop before creating the worktree with a specific recoverable error. It should not create orphan worktrees and then show only the generic Failed to start the conversation message.

Additional information

Related but distinct reports checked:

• Desktop-created worktree thread exists locally but never appears in Codex Desktop thread list #14519: the thread/session exists but is missing from the Desktop project list. In this case no thread/session is created at all.
• Codex Desktop managed worktree creation reports AGENTS.override.md failure even though git worktree add succeeds and no ls-files command is spawned #29670: worktree creation reports a post-create AGENTS.override.md failure. In this case setup reports success and the failure occurs afterward, before thread/start.

Suggested diagnostic improvement: include the caught conversation-start error and the intended project/workspace identifiers in sanitized structured logs, and remove or reuse the just-created worktree when conversation start fails.