[Regression] Windows SSH worktree threads are not grouped under their saved project in the Codex App sidebar

Open 💬 5 comments Opened Jul 10, 2026 by xiaokening

Summary

This appears to be a regression of [#10522](<https://github.com/openai/codex/issues/10522>).

A task created in a Codex-managed Git worktree on an SSH remote host exists and can be opened through direct navigation, but it is not displayed under its corresponding saved project in the Windows Codex App sidebar.

Earlier Codex App versions grouped these worktree tasks under the original project. Fully quitting and restarting the app does not restore the missing sidebar association.

Environment

  • OS: Windows 11 Pro 64-bit, version 10.0.22000 (build 22000)
  • Codex App: 26.707.3748.0
  • Remote app-server: 0.144.1
  • Flow: Windows Codex Desktop -> SSH remote host -> saved Git project -> Worktree task
  • Worktree state: detached HEAD, as expected for a newly created Codex worktree

Steps to reproduce

  1. Add and open a Git project on an SSH remote host in the Windows Codex App.
  2. Start a new task under that saved project and select the Worktree environment.
  3. Wait for Codex to create the worktree and start the task successfully.
  4. Return to the sidebar and inspect the original project group.

Expected behavior

The worktree task should appear under the same saved project in the sidebar while continuing to execute from its own worktree directory.

This matches the documented behavior that worktrees allow multiple independent tasks in the same project.

Actual behavior

The worktree task is absent from the saved project group.

The task still exists and can be opened through direct navigation. The thread API returns it normally, and the worktree is healthy. A complete app restart does not fix the grouping.

Diagnostics

The following checks all succeed:

  • The main checkout and worktree have the same remote.origin.url.
  • git rev-parse --git-common-dir from the worktree resolves to the main checkout's .git directory.
  • git worktree list --porcelain lists the worktree correctly.
  • The Codex App log reports:<br>[worktree-service] [worktree-create] owner-thread-set
  • The remote host remains connected and the task can be opened directly.
  • The task's recorded cwd is the Codex-managed worktree path rather than the saved project root.

This suggests that the worktree/thread association is created successfully, but the sidebar does not map the worktree back to the canonical saved project.

Workaround

Create a separate project-root entry task that references the original worktree thread and preserves the original execution cwd. This restores sidebar access but creates a duplicate entry and should not be necessary.

Related issues

  • [#10522](<https://github.com/openai/codex/issues/10522>) — exact previous issue, now closed
  • openai/codex#23418 — similar missing Desktop project association for a remote-created worktree thread
  • openai/codex#31623 — related repository-aware grouping behavior for remote worktree sessions

This report is specifically about a worktree created from the Windows Codex Desktop UI for an SSH remote project, not a mobile-created thread. The requested behavior is only correct project/sidebar organization; the worktree execution cwd should remain unchanged.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗