Codex App worktree fork thread hidden under project-sorted sidebar

Open 💬 5 comments Opened Jun 7, 2026 by LGSME

💡 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.602.40724

What subscription do you have?

plus

What platform is your computer?

windows11

What issue are you seeing?

Feedback ID: 019ea1b4-58d9-7d60-a174-a66817e0be30

Problem:
After forking a Codex conversation into a new worktree, the forked thread does not appear in the default sidebar project-sorted view. It appears only after switching sidebar sorting to chronological order.

Expected:
Forked worktree threads should remain visible under the original project, or be shown clearly as a worktree child thread.

Actual:
The thread appears hidden/missing in project-sorted sidebar, making it look like the forked conversation was lost.

Environment:
Windows 11
Codex Desktop App
Original project path: D:\codexProjects\worktree_test
Worktree path: C:\Users\Xiao\.codex\worktrees\2103\worktree_test

What steps can reproduce the bug?

Feedback ID / Session ID:
019ea1b4-58d9-7d60-a174-a66817e0be30

Steps to reproduce:

Open Codex Desktop App on Windows.
Open a saved project backed by a Git repository, for example:

D:\codexProjects\worktree_test

Keep the sidebar organization set to:

Organize sidebar -> Sort by -> By project

Start a conversation in that project.
From the conversation, choose to fork/derive the conversation into a new worktree.
Wait until worktree creation completes.
Continue chatting in the forked worktree conversation.
Click the original conversation in the left sidebar, or inspect the project-sorted sidebar.
The forked conversation appears to be missing from the sidebar.
Change sidebar sorting to:

Organize sidebar -> Sort by -> Chronological order

The forked conversation appears again.

Actual result:
The forked worktree conversation is hidden or not discoverable in the default project-sorted sidebar view. It looks like the forked conversation was lost.

Expected result:
A conversation forked into a new worktree should remain visible in the sidebar under the original project, or under a clear worktree child/group entry. It should not disappear from the default project-sorted view.

Notes:
The Git worktree itself is created successfully. The issue appears to be only with sidebar grouping/indexing.

Original project path:
D:\codexProjects\worktree_test

Forked worktree path:
C:\Users\Xiao\.codex\worktrees\2103\worktree_test

Observed Git state:
The forked conversation cwd was:
C:\Users\Xiao\.codex\worktrees\2103\worktree_test

The worktree existed and was listed by git worktree list.

Possible cause:
The project-sorted sidebar may be grouping conversations by physical cwd/project path. Since the forked worktree cwd is under:
C:\Users\Xiao\.codex\worktrees\...
instead of the original saved project path:
D:\codexProjects\worktree_test
the forked thread may not be associated with the original project group.

Code / commands used to create the minimal repo:

mkdir D:\codexProjects\worktree_test
cd D:\codexProjects\worktree_test
New-Item simple1.txt -ItemType File
git init -b main
git add .
git commit -m "Initial commit"

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

#26622
#26749

Powered by Codex Action

LGSME · 2 months ago

I reviewed the suggested duplicates.

#26622 is related and may share the same root cause, but my issue is a more specific user-visible failure mode:

The worktree is created by Codex App itself via "fork conversation to new worktree", not by manually opening external worktrees with codex app ..
The forked conversation/thread exists and is recoverable.
However, in the default sidebar organization mode "Sort by project", the forked thread is not discoverable and appears to be lost.
Switching the sidebar to chronological order makes the same forked thread appear again.

So the problem is not only that worktrees are shown as separate projects. The concrete bug is that a Codex-created worktree fork can become hidden/missing from the default project-sorted sidebar, which makes users believe the forked conversation content was deleted.

#26749 seems related at the product-design level, but it is broader and framed as an enhancement for reusable existing worktrees. My report is a narrower bug in current sidebar/session visibility.

Please do not close this as a duplicate unless the fix for #26622 explicitly covers this case:

Start from a saved project.
Fork the conversation into a Codex-created worktree.
Keep sidebar sorting set to "By project".
Verify that the forked thread remains visible under the original project or a clearly discoverable worktree child group.
Verify that switching between the original thread and forked thread does not make the forked thread appear lost.

Feedback ID / Session ID:
019ea1b4-58d9-7d60-a174-a66817e0be30

Original project path:
D:\codexProjects\worktree_test

Codex-created worktree path:
C:\Users\Xiao\.codex\worktrees\2103\worktree_test

Expected:
Codex-created worktree fork threads should stay discoverable in the default project-sorted sidebar.

Actual:
The thread appears missing in project-sorted mode and only reappears after switching to chronological sorting.

qiushui95 · 2 months ago

I’m seeing the same issue. After forking a conversation into a Codex-created worktree, the forked thread disappears from the project-sorted sidebar and only becomes visible again after switching the sidebar sorting to chronological order. The worktree itself is created successfully.

Environment:

Codex App: 26.616.51431
Windows 11 Pro, build 26200
x64

devansh-jain-18 · 2 months ago

Related to #22316 from the discoverability side.

For users trying to continue work in an existing worktree with fresh context, fork-related worktree threads need to remain easy to find and reason about. Today the available choices are awkward: fork preserves context, new worktree changes the checkout, and opening an existing managed worktree as a folder is not a clear first-class path in the UI.

A visible "New thread here" / "Use existing worktree" affordance, plus reliable sidebar grouping for forked/worktree threads, would make this workflow much less confusing.

leadingproblemsolver · 20 days ago

The repeated “thread exists in chronological/CLI/deep-link, but disappears only in project grouping” evidence suggests the grouping key should not be the thread's physical cwd alone.

A fork into a worktree changes the workspace instance, not necessarily the logical project identity. I would persist those separately on the fork:

thread_id
project_id              // inherited from source thread/project
workspace_instance_id   // new worktree identity
cwd                     // physical worktree path
forked_from_thread_id
worktree_git_common_dir / repo identity

Then sidebar projection becomes:

Projects
  -> group by durable project_id
  -> optionally nest/display workspace_instance/worktree beneath it

rather than attempting to rediscover project membership from the new ~/.codex/worktrees/... cwd after the fork.

That also gives a useful reconciliation fallback for older rows: if project_id is missing, infer a candidate from forked_from_thread_id first, then from normalized repo identity (git common dir / remote+root), and persist the repaired association. Physical path matching should be lower-confidence evidence because managed worktrees intentionally move outside the original project path.

The deterministic app-server reproduction above is especially useful for a regression:

source thread belongs project P
thread/fork -> managed worktree W
fork persists before renderer/index refresh
=> fork.project_id == P
=> project-sorted sidebar contains fork without deep-link/open/new turn
=> chronological and project projections reference same thread id

The invariant is: forking execution state into a new checkout must not sever the durable logical project association.