codex - 💡(How to fix) Fix "Fork into New Worktree" groups the new thread under the wrong project in the sidebar for remote workspaces

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

26.513.31313 (2867)

What subscription do you have?

chatgpt plus

What platform is your computer?

codex app runs on Darwin 25.4.0 arm64 arm, and it connects to a remote unbutu: Linux 6.8.0-87-generic x86_64 x86_64

What issue are you seeing?

When using Codex Desktop's built-in remote workspace feature, right-clicking a thread and selecting "Fork into New Worktree" can create the worktree from the correct source repository, but the new thread is shown under the wrong project group in the sidebar.

This appears to be a sidebar grouping bug, not a git/worktree creation bug.

Environment

• Codex Desktop
• Remote workspace connected to a Linux development host via the built-in remote workspace feature
• Multiple repositories/worktrees from the same Git remote are present on that remote host

What steps can reproduce the bug?

1. Connect Codex Desktop to a remote Linux host using the built-in remote workspace feature.
2. Have at least two workspace roots on that host:
   • /remote/project-A
   • /remote/project-B
3. Ensure both workspaces point to the same Git remote URLs, but they are not the same repository/worktree lineage.
4. Open a thread under project-A.
5. Right-click the thread and select "Fork into New Worktree".
6. Wait for the new worktree session to appear in the sidebar.

What is the expected behavior?

The new thread should be grouped under:

• the newly created Codex worktree derived from project-A, or
• at minimum, the project-A group.

Additional information

Actual Behavior

The new thread is grouped under a different existing project in the sidebar, such as project-B, even though the worktree was actually created from project-A.

Sanitized Example

Actual source project:

• /remote/project-A

Another unrelated workspace visible in the sidebar:

• /remote/project-B

New Codex-created worktree:

• /remote/.codex/worktrees/<id>/project-A

What should happen:

• the new thread is grouped under project-A or the new Codex worktree group

What actually happens:

• the new thread is grouped under project-B

Why this is clearly incorrect

The underlying Git metadata shows that the newly created Codex worktree belongs to project-A, not project-B.

Sanitized Git metadata example:

• project-A

  • git rev-parse --show-toplevel => /remote/project-A
  • git rev-parse --git-common-dir => /remote/project-A/.git

• project-B

  • git rev-parse --show-toplevel => /remote/project-B
  • git rev-parse --git-common-dir => /remote/another-root/.git

• new Codex worktree

  • git rev-parse --show-toplevel => /remote/.codex/worktrees/<id>/project-A
  • git rev-parse --git-common-dir => /remote/project-A/.git

So the new Codex worktree shares Git common-dir with project-A, not project-B.

Additional Technical Notes

From investigation of the app behavior:

1. The "Fork into New Worktree" flow passes the correct source workspace root.
2. The actual create-worktree operation also uses the correct source workspace root.
3. The problem happens later, when the sidebar decides which project group should own the new pending worktree thread.

The likely root cause is that sidebar grouping prefers matching by originUrl before commonDir.

That is unsafe when multiple workspace roots share the same remote origin URL.

In this case:

• project-A
• project-B
• the new Codex worktree

all share the same origin / upstream remote URLs, but only project-A shares the correct commonDir with the newly created worktree.

If the grouping logic uses originUrl first, it can incorrectly match the new thread to the first project group with the same remote, which explains the wrong sidebar placement.

Suggested Fix

When mapping a worktree-backed thread back to a sidebar project group:

1. Prefer matching by commonDir
2. Only fall back to originUrl if commonDir is unavailable

commonDir is the reliable identity signal here; originUrl is not unique enough.

Impact

This is confusing because:

• the worktree is created from the correct source
• but the UI makes it look like it belongs to a different project
• users can easily think the fork operation targeted the wrong repository

If helpful, I can provide sanitized logs showing:

• the correct source workspace used during create-worktree
• the resulting Codex worktree path
• the incorrect sidebar grouping outcome