[Remote/Android/macOS] Worktree threads omitted from project list despite shared projectId

[chonorov]

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

26.901.31953 (build 7868); bundled codex-cli/app-server 0.153.1

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

ChatGPT Android Remote shows a root-checkout chat inside a saved local project but omits an active Codex-managed worktree chat belonging to the same project.

Desktop app-server returns both threads through thread/list and thread/read. Both are active/non-archived top-level chats with the same projectId and hostId. The only material difference is cwd:

• visible: canonical saved project root
• missing: $CODEX_HOME/worktrees//

Android opens the saved project, displays only the root-checkout chat, and reports "No more threads." The missing chat remains healthy and readable on Desktop, so this is a Remote project association/list filtering bug, not data loss.

Re-pairing Remote, restarting both apps, and reinstalling the Android app did not help.

What steps can reproduce the bug?

1. On macOS, add a Git repository as a saved local project in ChatGPT/Codex Desktop.
2. Create one top-level chat in the canonical local checkout.
3. Create another top-level chat for the same project using a Codex-managed worktree under $CODEX_HOME/worktrees.
4. Confirm through Desktop app-server that both chats have the same projectId and hostId and are not archived.
5. Connect ChatGPT Android Remote to that Mac using the same ChatGPT account and workspace.
6. Open the saved project on Android.
7. Observe that only the canonical-root chat is listed and the UI says "No more threads," while the worktree chat remains active and readable on Desktop.

Exact thread and project IDs were provided privately to OpenAI Support and are intentionally omitted here.

What is the expected behavior?

All non-archived chats associated with the same saved projectId and hostId should be discoverable under that project in Android Remote. A worktree chat should keep its actual execution cwd but be grouped under the canonical repository/project instead of being silently omitted.

Additional information

Environment:

• ChatGPT/Codex Desktop 26.901.31953, build 7868
• bundled codex-cli/app-server 0.153.1
• macOS 26.6.2 (25G83), Apple Silicon
• Android ChatGPT Remote, same account and workspace; exact Android build is not exposed on the affected screen

Possibly related local log signals:

• Remote can report state=connected together with nextError.code=connection-failed.
• Bundled runtime warns about invalid experimental feature enablement keys apps_mcp_path_override and local_thread_store_compression.

Likely boundary: Android Remote appears to use literal thread cwd during project grouping/filtering instead of the shared projectId or canonical Git repository identity.

Related reports:

• Codex Remote omits desktop-created threads after latest Codex Desktop update #35800: Remote omits Desktop-created chats and reaches "No more threads"
• Mobile remote: group Git worktree sessions by repository instead of exact cwd #31623: Mobile Remote groups Git worktree sessions by exact cwd
• Mobile remote-created worktree thread is not associated with project in Codex Desktop sidebar #23418: Worktree thread exists locally but is not associated with its project
• Mobile Remote briefly shows a local project/thread, then removes both after sync #24462: Mobile synchronization removes an otherwise healthy local project/chat

No destructive state reset or handoff was performed because the omitted worktree chat was active.

[github-actions]

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

• Android Remote project list differs from Desktop: stale folders remain and a saved project is missing #42919
• [Windows][Remote iOS] Dragging a misplaced Remote worktree thread into its project breaks its worktree binding #41835

Powered by Codex Action

[84dnnvbdvp-debug]

One source-level discriminator may help separate Remote client grouping from app-server thread assignment here.

In current codex app-server, thread/list exposes projectId and cwd as separate optional filters. The documented contract is that projectId selects threads assigned to that project, while cwd is an additional literal working-directory filter. The project APIs are separately SQLite-backed (project/list, project/read, etc.), and reconnect is supposed to recover authoritative project state with project/list + thread/list.

Given your strongest observation — the root thread and managed-worktree thread already have the same projectId and hostId — I’d capture the exact thread/list params Remote sends when that saved project is opened:

• If it sends projectId=<saved project> plus cwd=<canonical root>, the worktree omission is explained by an over-constrained client query.
• If it omits projectId and groups/filter threads by cwd client-side, that points to the same identity mistake from a different path.
• If it sends only the correct projectId and app-server’s response itself omits the worktree thread, the defect moves server-side/store-side.

A useful regression would be: two non-archived top-level threads, same projectId, one at the canonical checkout and one under $CODEX_HOME/worktrees/...; opening the saved project in Remote must discover both while preserving each thread’s actual execution cwd. cwd should remain execution metadata, not silently become project identity.

This also makes #42919 more diagnostic rather than merely similar: that report observed thread/list during Remote reconnect but no project/list, and its visible mobile project set could be reproduced from conversation working directories. Together the two reports suggest checking the Remote request shape before changing persisted thread/project assignment.

[chonorov]

Fresh controlled retest on the same Mac/Android pair after updating Codex:

• Codex Desktop: 26.901.41600
• bundled codex-cli/app-server: 0.153.4
• ChatGPT Android: 1.2026.237 (2623716)

Results:

1. Root/root control: after creating a second top-level chat at the canonical checkout, Android Remote immediately showed both chats under the saved project.
2. Direct worktree case: I created a new top-level task directly in a managed worktree under $CODEX_HOME/worktrees/<id>/<repo>. Android Remote showed it in the same saved project with the Worktree badge. Opening it loaded the thread and displayed the exact diagnostic reply REMOTE_WORKTREE_DIAG_OK.
3. Handoff case: I moved an existing root-checkout chat to a managed worktree. Its worktree successor also remained discoverable and openable from the Android project list.

So the original user-visible omission no longer reproduces on Desktop 26.901.41600 / app-server 0.153.4. It did reproduce on the originally reported 26.901.31953 / 0.153.1 build, so the update may have fixed or changed this path.

One instrumentation caveat remains. Local app-server logs show multiple Remote-triggered thread/list requests when the Android project is opened, but the current trace records only method, connection ID, and request ID, not request params. I therefore could not directly prove whether Android sent projectId, cwd, both, or neither. In a separate raw bundled app-server check, thread/read could read the handoff worktree successor while raw thread/list did not enumerate that successor globally, by its exact worktree cwd, or by the saved project's internal ID; the persisted thread row also had no direct project_id. Despite that, the Desktop host bridge/Android UI grouped and opened it correctly on the current build.

This looks fixed from the user's perspective in 26.901.41600, but the raw thread/list versus host-bridge aggregation discrepancy may still be worth keeping in the regression coverage. The useful regression is still: two non-archived top-level project tasks, one at the canonical checkout and one created directly in a managed worktree, must both appear and open in Android Remote.