codex - 💡(How to fix) Fix Codex Desktop: chat creation error when creating new chat as a worktree

Summary

Chat creation in Codex Desktop can fail when creating a new chat as a worktree from a project. The chat briefly appears under the correct project in the left sidebar, then disappears completely from the sidebar. If the user switches away, the thread becomes effectively unreachable from the UI.

A later manual diagnostic/rerouting attempt caused the same thread to reappear under the wrong project. That wrong-project result is evidence about Codex's project mapping/recalculation, but it was not the original user-visible failure.

Environment

• App: Codex Desktop
• Windows package: OpenAI.Codex 26.519.5221.0
• CLI version recorded in thread DB: 0.133.0-alpha.1
• OS: Windows 10 Home, version 2009, build 26200
• Mode: worktree (last-used-continue-in-mode = worktree)

Chat / thread UUID

• Thread id / chat UUID: 019e5a83-8e49-7370-9b5f-e8f83b9089c1

Projects involved

• Project where the chat was created: D:\shippingAgent-Master
• Codex-created worktree cwd for the thread: C:\Users\sufin\.codex\worktrees\4a0c\shippingAgent-Master
• Wrong project seen only after manual rerouting/debug attempt: D:\shippingAgent-customs-uiux
• Wrong project UI label: Status Panel - shippingAgent

Reproduction observed

1. In Codex Desktop, create a new chat from the shippingAgent-Master project while using worktree mode.
2. Send the first message, e.g. hi.
3. For about a second, the new chat appears under the correct shippingAgent-Master project in the left sidebar.
4. The chat then disappears completely from the sidebar.
5. If the user switches to another chat, they cannot find this thread again from the sidebar.

Actual result

The newly-created worktree chat disappears from the project sidebar shortly after creation.

The thread still exists in local storage, but is no longer reachable through the expected project list in the UI.

Expected result

A chat created from shippingAgent-Master in worktree mode should remain listed under shippingAgent-Master.

If Codex creates an isolated worktree like:

C:\Users\sufin\.codex\worktrees\4a0c\shippingAgent-Master

then the sidebar should still associate that thread with the source project/root where the user clicked New Chat:

D:\shippingAgent-Master

Thread evidence

Specific observed thread:

• Thread id: 019e5a83-8e49-7370-9b5f-e8f83b9089c1
• Initial message: hi
• Title after creation: Greet user / later hi
• SQLite threads.archived: 0
• SQLite threads.first_user_message: hi
• SQLite threads.preview: hi

SQLite threads row:

{
  "id": "019e5a83-8e49-7370-9b5f-e8f83b9089c1",
  "title": "hi",
  "cwd": "\\\\?\\C:\\Users\\sufin\\.codex\\worktrees\\4a0c\\shippingAgent-Master",
  "source": "vscode",
  "thread_source": "user",
  "archived": 0,
  "preview": "hi",
  "first_user_message": "hi",
  "cli_version": "0.133.0-alpha.1",
  "model": "gpt-5.5",
  "reasoning_effort": "high"
}

session_index.jsonl also contains the thread:

{"id":"019e5a83-8e49-7370-9b5f-e8f83b9089c1","thread_name":"Greet user","updated_at":"2026-05-24T15:04:01.401024Z"}

So the thread is not deleted or archived. It is a sidebar/project-indexing problem during or shortly after worktree chat creation.

Screenshot evidence

Screenshots captured during the conversation show:

1. Immediately after creation, the hi chat is visible under shippingAgent-Master in the left project sidebar.
2. Shortly after, the same chat is no longer listed under shippingAgent-Master, making it appear orphaned/lost.
3. After a manual diagnostic/rerouting attempt, the same chat reappears under the wrong project, Status Panel - shippingAgent / D:\shippingAgent-customs-uiux.

The screenshots are embedded in the local Codex session as user-provided input_image items. I could not attach them through gh issue edit; GitHub's browser uploader supports drag-and-drop attachments, but the CLI edit path does not expose the same attachment upload flow.

Additional diagnostic: manual rerouting caused wrong-project appearance

After the chat disappeared, we tried to manually repair Codex's local UI state by adding/updating thread-workspace-root-hints in .codex-global-state.json.

A watcher waited until Codex Desktop exited, then mapped five shippingAgent-Master worktree threads, including this one, to:

D:\shippingAgent-Master

Repair log excerpt:

2026-05-24T18:18:07.6576980+03:00 Watcher started; waiting for Codex desktop processes to exit.
2026-05-24T18:18:44.1923437+03:00 Repair complete: mapped 5 thread ids, including 019e5a83-8e49-7370-9b5f-e8f83b9089c1

After reopening Codex Desktop, Codex recalculated/overwrote the mapping for this thread to the wrong project:

CurrentHint: D:\shippingAgent-customs-uiux
ActiveRoots: D:\shippingAgent-Master
last-used-continue-in-mode: worktree

At that point, the thread reappeared in the UI, but under the wrong project:

Status Panel - shippingAgent / D:\shippingAgent-customs-uiux

This wrong-project appearance is secondary evidence. The original bug is that a newly-created worktree chat disappears from the expected project almost immediately after creation.

Why this matters

Users can lose active work immediately after creating a new chat. The thread still exists on disk, but if it disappears from the project sidebar, switching away makes it hard or impossible to return to the conversation from the UI.

Related issue

Possibly related to sidebar/history issues such as #20493, but this report is specifically about chat creation in worktree mode: the new chat briefly appears under the correct project, then disappears from the sidebar even though the local thread row/session file exist.