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

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

• #32071

Powered by Codex Action

Update: this is no longer reproducible in my current setup.

The installed Windows package currently reports OpenAI.Codex 26.707.3748.0. Newly created tasks in Codex-managed worktrees on the SSH host are now automatically shown under the corresponding saved project in the sidebar, while their execution cwd correctly remains under ~/.codex/worktrees/.../<repo>.

I was also able to remove/archive the temporary project-root entry tasks that had been created as a workaround; the original worktree threads remain visible and usable.

The suggested #32071 appears to cover the same user-visible symptom, although this report has the more specific Windows Desktop -> SSH remote project -> managed worktree reproduction and diagnostics.

Since the expected sidebar grouping is working again, I am closing this as resolved. If the association disappears again for newly created worktrees, I will reopen with the affected app build and thread metadata.

Reopening: the sidebar association regressed again after updating the Windows app.

Current environment:

• Windows package: OpenAI.Codex 26.707.6957.0
• Remote host: dev1, connected and available
• Saved project: /mnt4/lsc/data_synthesis
• Flow: Windows Codex Desktop -> SSH remote host -> saved project -> Codex-managed worktrees

This time the failure is partial rather than all-or-nothing. In the expanded data_synthesis sidebar, ChestX-Reasoner is visible as a worktree task, along with normal project-root tasks. However, these four existing worktree tasks are missing from the same project group:

• μ²Tokenizer
• CORTEX
• V2T-COT
• KneeCoT

The app's thread API still returns all four original threads. They are not lost, and their recorded working directories remain valid Codex-managed worktree paths:

• ~/.codex/worktrees/5785/data_synthesis
• ~/.codex/worktrees/bce6/data_synthesis
• ~/.codex/worktrees/b23c/data_synthesis
• ~/.codex/worktrees/aa8d/data_synthesis

The saved data_synthesis project is also still returned by the project API, and the remote host is not unavailable. Temporary project-root workaround entries had previously been archived after the sidebar started working, so the missing items here are the original worktree threads, not archived duplicates.

This provides a useful differential case within the same project and host: one managed-worktree task is grouped correctly while four other valid managed-worktree threads are omitted. The regression appeared again after moving from package 26.707.3748.0 to 26.707.6957.0.

Another recurrence after updating the Windows app.

Current package:

• OpenAI.Codex 26.707.8168.0

The same four original SSH worktree threads are again missing from the data_synthesis project sidebar:

• μ²Tokenizer
• CORTEX
• V2T-COT
• KneeCoT

Read-only checks still show:

• all four original threads are returned by the app thread API;
• each still records its valid ~/.codex/worktrees/.../data_synthesis cwd;
• the saved project /mnt4/lsc/data_synthesis is returned by the project API;
• remote host dev1 is available.

This recurred after the previous 26.707.6957.0 report. The sidebar association has now repeatedly disappeared and reappeared across app updates without any change to the underlying remote threads or worktrees. I restored the existing archived project-root entry tasks as a temporary navigation workaround so work can continue; no new duplicate entries were created.

Independent reproduction on a newer Windows App build.

Environment

• Codex App: OpenAI.Codex 26.707.8479.0
• Local platform: Windows NT build 26220, x64
• Connection: Windows Codex App -> SSH remote Linux host
• Remote Codex/app-server: primarily 0.144.2 (one connected host reported 0.144.1)
• Affected tasks are disproportionately those using Codex-managed remote worktrees under ~/.codex/worktrees/.../<repo>

Observed behavior

The failure is intermittent and partial: the SSH host reaches the connected state and thread/list completes, but some existing remote sessions are not loaded or shown under their saved project. Sessions backed by remote worktrees are affected most often.

Fully quitting and reopening the App does not reliably restore every missing session.

During affected App launches, the Desktop logs repeatedly contain:

thread/read -> error code -32600: thread not loaded: <redacted-thread-id>
Failed to read pinned thread

On 2026-07-13, this pattern appeared in 12 App log files (90 matching log lines). The same logs show the remote connection reaching connected and successful thread/list responses, so this appears to be a thread hydration/project-association problem after connection rather than a simple SSH connection failure.

The remote host names, project paths, thread IDs, and raw logs are intentionally omitted from this public comment. The worktrees themselves use detached HEAD as expected and remain valid.

Expected behavior

Once an SSH remote is connected, all of its existing sessions should load and be grouped under the corresponding saved project. Codex-managed worktree sessions should map back to the canonical project while retaining their worktree cwd.

This matches the regression described here and confirms it is still present after 26.707.8168.0. I can provide sanitized logs privately if useful.

Additional macOS Remote Control reproduction with a cross-project trigger:

Environment

• Controller: macOS Codex Desktop
• Remote host: macOS Studio running Codex Remote Control
• Codex Desktop build observed on the host: 26.715.72359
• Target: saved Git project with a mix of root-checkout threads and Codex-managed worktree threads
• Remote connection status remained connected throughout

Observed behavior

1. The controller connected successfully to the remote host.
2. The target project appeared in the remote sidebar.
3. Only threads whose cwd exactly matched the saved project root appeared beneath it.
4. Threads under $CODEX_HOME/worktrees/<id>/<repo> were missing, although:

• the threads remained intact and unarchived on the host;
• direct thread deep links opened successfully;
• the host received a fresh thread/list request from the controller;
• the worktree threads shared the same Git origin as the saved project.

1. Removing two unrelated saved remote projects from the controller sidebar caused the missing worktree threads for the target project to appear immediately.
2. No re-pair, restart, Git operation, thread mutation, or host-side data change was required for the threads to reappear.

Why this detail matters

The unrelated-project removal strongly suggests stale or colliding client-side remote project/sidebar indexing, rather than only a failure to map a worktree path to its canonical project. One project's visibility should not depend on whether unrelated remote projects are saved.

Expected behavior

Remote worktree threads should remain grouped under their owning saved project, and adding or removing unrelated remote projects should not change their visibility.

I am intentionally omitting repository names, thread titles, IDs, screenshots, and raw logs because they contain private workspace information. Redacted diagnostics can be provided if maintainers specify what is needed.

I can reproduce a cross-client variant of this issue with two Codex Desktop clients connected to the same project on the same SSH remote host.

• Desktop client A creates a new thread using a Codex-managed worktree.
• On client A, the thread is correctly grouped under the original project.
• When the same thread is opened from Desktop client B, it appears under Recent instead of the original project.
• The thread and worktree remain fully usable from client B; only the sidebar/project grouping is incorrect.

This client-to-client difference suggests that the worktree-to-project association used by the sidebar may be stored or resolved per Desktop client rather than consistently reconstructed from the remote thread/worktree metadata.