›_ Codex Issues
Codex Issues / #10522

Codex App: Worktree threads not associated with project in Codex App sidebar

Resolved 💬 9 comments Opened Feb 3, 2026 by mdsavarese Closed Feb 5, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

Codex CLI 0.94; Codex App 260202.0859

What subscription do you have?

Pro

Which model were you using?

gpt-5.2-codex

What platform is your computer?

Darwin 25.2.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Codex App

What issue are you seeing?

New local threads are correctly grouped by project in the sidebar. However, new threads created in work trees are not associated with the project in the sidebar (they only show up when switching to chronological view).

What steps can reproduce the bug?

  1. Create a new project (mdkir test_codex_project; cd test_codex_project; git init; uv init; git add --all; git commit -m "initial")
  2. Add project to Codex App
  3. Start new thread in test_codex_project; select "Work in your local project". Prompt with anything ("Write hello_world.json to the repo root"). Thread correctly shows up in sidebar under test_codex_project
  4. Start new thread in test_codex_project; select "Work in a parallel work tree". Prompt with anything ("Write hello_world_v2.json to the repo root"). Thread appears for a split second in the sidebar under test_codex_project, then disappears.
  5. Check that thread is visible in chronological list view in sidebar.

What is the expected behavior?

Worktree threads associated with a project should be grouped with other threads associated with that project

Additional information

_No response_

View original on GitHub ↗

9 Comments

mdsavarese · 5 months ago

Resolved (for me) as of version 260204.1342 (531); unless others are still having problems, I'll close this issue.

etraut-openai contributor · 5 months ago

Thanks for confirming the fix.

marcocello · 4 months ago

Is the issue solved?

I am on 26.305.950, and new threads created in worktrees are not associated with the project in the sidebar disappear (they only show up when switching to chronological view).

camopy · 4 months ago

I'm experiencing the same since the app launch

morgler · 4 months ago

Version: 26.318.11754 (1100)

I'm also confused. They're called "permanent" work trees, but each time I start a thread, Codex creates a new separate worktree. The threads don't show up under the worktree, but move to the project of the source repo in the sidebar. The threads also don't seem to be aware to which worktree in the sidebar they belong.

rithamnatani · 3 months ago

Still having this issue.

A conversation created in a separate worktree disappears from the main Threads sidebar after I switch to another thread, but it still remains listed under Settings → Worktrees → Conversations for that same worktree.

Environment

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

What I see

  • Worktree still exists
  • Missing conversation still appears in Settings → Worktrees
  • Sidebar for that worktree does not show the conversation
  • Clicking Show more / fully expanding the list does not help
  • Restarting the app does not help

Expected
The worktree conversation should still appear in the sidebar and be selectable.

Actual
It disappears from the sidebar, even though the app still knows it exists internally.

<img width="296" height="452" alt="Image" src="https://github.com/user-attachments/assets/53f031be-61f8-4778-a189-81d3541df42c" />

<img width="714" height="635" alt="Image" src="https://github.com/user-attachments/assets/b28d9709-3a21-41bc-9f2e-43386de74ebf" />

marcocello · 3 months ago

Seems solved with Version 26.409.20454 🥳

<img width="291" height="56" alt="Image" src="https://github.com/user-attachments/assets/18e111cf-088b-474b-8827-ed4255260a89" />

andybergon · 2 months ago

I?m seeing what appears to be a regression of this issue on current Windows Desktop.

Environment:

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

Symptom:

  • A Codex-managed worktree thread appears in Chronological list.
  • The same thread does not appear under the owning project when organizing By project.

This is not the broader recent-window problem: the missing thread is active, unarchived, and rank 3 by updated_at_ms among active direct local threads.

The local state points to a project-association problem:

  • Saved project root: C:\Users\<user>\repos\foo
  • Thread cwd: \\?\C:\Users\<user>\.codex\worktrees\<id>\foo
  • .codex-global-state.json has no thread-workspace-root-hints entry for this thread.
  • Older worktree threads for another repo, bar, do have root hints mapping the worktree thread back to the owning project.

Git can resolve the worktree owner:

git common dir: C:/Users/<user>/repos/foo/.git
git dir: C:/Users/<user>/repos/foo/.git/worktrees/foo2

So this looks like the original ?worktree threads not associated with project? bug is still reproducible, or has regressed in a newer code path. More detailed evidence is also relevant to #16811.

SynNova · 2 months ago

Adding a Windows data point/workaround, because this looked project-specific rather than a general failure of all worktrees.

Environment:

  • Codex Desktop 0.131.0-alpha.9
  • Windows
  • Managed worktrees under $CODEX_HOME\worktrees\...

Symptoms:

  • Worktree chats created from one local project briefly existed but did not remain grouped under the project in the sidebar.
  • If the chat was pinned, it stayed accessible under Pinned, but still was not associated with the project group.
  • Other projects in the same Codex install grouped worktree chats correctly.
  • The worktree directories and session/thread records existed locally; they were not archived.
  • Some hidden worktree sessions also still had active goals/processes even though they were not visible under the project.

What was different in the affected project:

  • The project originally started as a local-only checkout, with no GitHub remote.
  • Adding a local bare origin and later switching master to main did not fix the sidebar association.
  • After adding a GitHub origin, the original folder still reproduced the problem.
  • The branch selector still showed legacy/local state such as master until those refs were cleaned up.

Workaround that fixed it:

  1. Created a private GitHub repository for the project.
  2. Pushed the project to GitHub with main as the default branch.
  3. Created a brand-new local folder via git clone https://github.com/... instead of reusing the original local checkout.
  4. Updated the Codex local environment/AGENTS instructions to treat the new clone path as the canonical checkout.
  5. Opened that fresh clone in Codex and created a new worktree chat. It stayed associated with the project.

Possible trigger:
The app may be anchoring project/sidebar identity to the workspace identity captured when the project is first added. If a project starts as local-only or uses a file-path remote, then later gets a GitHub remote/default branch cleanup, existing Codex project metadata may not fully re-key. A fresh GitHub clone creates a clean project identity and avoids the issue.