›_ Codex Issues
Codex Issues / #16811

Worktree conversation remains listed in Settings but disappears from sidebar thread list

Open 💬 4 comments Opened Apr 4, 2026 by rithamnatani
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.325.31654

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.28000.0 x64

What issue are you seeing?

A conversation created in a separate worktree disappears from the main Threads sidebar after I switch to another thread, even though the conversation still appears under Settings -> Worktrees -> Conversations for that same worktree.

The worktree itself still exists, and Codex still appears to know the conversation belongs to it internally, but the conversation is no longer visible or selectable from the main sidebar.

I do not get an explicit error message. The issue is a UI/state inconsistency:

  • the conversation is present in Settings -> Worktrees
  • the same conversation is missing from the left sidebar thread list

<img src="https://github.com/user-attachments/assets/d2a0e372-31b7-4004-83c6-c58e87cf86dd " alt="Image" width="751" data-linear-height="643" />

(Both worktrees created less then 1hr ago)

<img src="https://github.com/user-attachments/assets/8b5aff66-cdb3-427c-97dd-ffad9f8a82b9 " alt="Image" width="305" data-linear-height="457" />

What steps can reproduce the bug?

  1. Open Codex desktop on Windows.
  2. Open or create a Codex-managed worktree for a project.
  3. Start a new conversation inside that worktree.
  4. Switch to a different thread.
  5. Return to the original project/worktree in the main Threads sidebar.

Observed result:

  • the original worktree conversation is no longer shown in the main Threads sidebar
  • the same conversation still appears under Settings → Worktrees → Conversations
  • the conversation is still accessible by going through Settings → Worktrees and clicking the worktree there

Additional checks already performed:

  • clicked Show more / expanded the sidebar list fully
  • restarted the app
  • confirmed the worktree still exists

After restart, the conversation still does not reappear in the sidebar.

I do not have a session ID to provide. I also do not have a text error message, because this appears to be a UI/state consistency issue rather than a surfaced runtime error.

What is the expected behavior?

A conversation created in a worktree should remain visible in the main Threads sidebar and remain selectable there after switching to another thread.

If the conversation still exists and is still attached to the worktree internally, the sidebar should continue to show it consistently.

The thread should not only be reachable through Settings -> Worktrees. It should also remain visible in the normal thread list.

Additional information

  • Codex version: 26.325.31654
  • Subscription: ChatGPT Plus
  • Installed from: winget / Microsoft Store
  • OS: Windows 11 Pro, Version 26H1 (OS Build 28000.1), x64
  • CPU: Intel i7-13700KH
  • GPU: RTX 4080
  • RAM: 32 GB DDR5

Relevant app state/details:

  • The missing thread is still listed in Settings → Worktrees → Conversations
  • The missing thread is still accessible by navigating through Settings -> Worktrees and clicking the worktree
  • The same thread is absent from the main Threads sidebar even after expanding the list and restarting the app
  • This suggests the worktree/thread association still exists, but the sidebar thread index/rendering is out of sync

Possibly related:

  • [#10522](<https://github.com/openai/codex/issues/10522>)
  • [#10917](<https://github.com/openai/codex/issues/10917>)
  • CXA-2592

My case differs slightly because the thread is still accessible through Settings → Worktrees, but it remains missing from the main Threads sidebar even after expanding the list and restarting the app.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

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

  • #15448
  • #15406
  • #15052
  • #16095

Powered by Codex Action

FEmser · 4 months ago

I got the same issue. Worktree-Threads are not shown in the sidebar but i can access them via Settings>Worktrees which is a big hassle.

marcusround · 4 months ago

Agreed this is a problem that needs fixing, but a little tip to help others with the problem -- You can also access worktree conversations via "Search", which is easier than going into settings.

andybergon · 3 months ago

I can reproduce what looks like the same bug on Windows, with one extra data point that seems to rule out the broader ?recent 50 threads? issue.

Environment:

  • Codex Desktop: 26.506.3741.0
  • Codex CLI: codex-cli 0.130.0-alpha.5
  • Platform: Windows

Observed:

  • A worktree thread is visible in Chronological list.
  • The same thread does not appear under the owning project when organizing By project.
  • The thread is active and recent, so this is not explained by falling outside the global recent-thread window.

Local state:

  • Thread title: Work on foo
  • Saved project root: C:\Users\<user>\repos\foo
  • threads.cwd: \\?\C:\Users\<user>\.codex\worktrees\<id>\foo
  • archived: 0
  • The thread is rank 3 among active direct local threads by updated_at_ms.

The important difference I found is in .codex-global-state.json:

  • electron-saved-workspace-roots contains C:\Users\<user>\repos\foo
  • thread-workspace-root-hints has no entry for this foo worktree thread
  • Older worktree threads for another repo, bar, do have thread-workspace-root-hints entries mapping Codex-managed worktree paths back to the saved project root.

Git can still resolve the relationship:

worktree cwd: C:/Users/<user>/.codex/worktrees/<id>/foo
git common dir: C:/Users/<user>/repos/foo/.git
git dir: C:/Users/<user>/repos/foo/.git/worktrees/foo2

So my current hypothesis is that the project sidebar grouping depends on either the thread cwd matching a saved project root or on thread-workspace-root-hints. For this newer worktree thread, the hint was not created, so the thread is still loaded and visible chronologically but cannot be associated with the owning project group.

Expected behavior:

  • Codex-managed worktree threads should be grouped under the owning saved project.
  • If thread-workspace-root-hints is the intended mechanism, it should be written consistently when a worktree thread is created.
  • If the hint is missing, the app should be able to derive the owner project from the worktree?s .git file / common git dir instead of dropping the thread from project grouping.