Skip to content

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

Closed
Closed
Codex App: Worktree threads not associated with project in Codex App sidebar#10522
Labels
appIssues related to the Codex desktop appbugSomething isn't working

Description

@mdsavarese
mdsavarese
opened on Feb 3, 2026

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

Activity

  1. mdsavarese
    added
    bugSomething isn't working
    on Feb 3, 2026
  2. github-actions
    added
    appIssues related to the Codex desktop app
    on Feb 3, 2026

  3. mdsavarese commented on Feb 5, 2026

    @mdsavarese
    mdsavarese
    on Feb 5, 2026
    Author

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

  4. etraut-openai commented on Feb 5, 2026

    @etraut-openai
    etraut-openai
    on Feb 5, 2026
    Contributor

    Thanks for confirming the fix.

  5. etraut-openai
    closed this as completedon Feb 5, 2026

  6. marcocello commented on Mar 6, 2026

    @marcocello
    marcocello
    on Mar 6, 2026

    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).

  7. camopy commented on Mar 15, 2026

    @camopy
    camopy
    on Mar 15, 2026

    I'm experiencing the same since the app launch

  8. morgler commented on Mar 20, 2026

    @morgler
    morgler
    on Mar 20, 2026

    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.

  9. rithamnatani commented on Apr 4, 2026

    @rithamnatani
    rithamnatani
    on Apr 4, 2026

    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.

    Image Image

  10. marcocello commented on Apr 15, 2026

    @marcocello
    marcocello
    on Apr 15, 2026

    Seems solved with Version 26.409.20454 🥳

    Image

  11. andybergon commented on May 12, 2026

    @andybergon
    andybergon
    on May 12, 2026

    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.

  12. SynNova commented on May 20, 2026

    @SynNova
    SynNova
    on May 20, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions