Codex desktop sidebar should support Connection → Project → Thread grouping for remote hosts

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

• #22947
• #23933
• #24271

Powered by Codex Action

Codex Action

Thanks for the duplicate suggestions. I reviewed #22947, #23933, and #24271.

I do not think this is a duplicate of those issues. The closest one is #23933, but this report is narrower: Mac-to-Mac remote control is usable here. Mac B's threads do appear on Mac A when the sidebar is sorted by Connections.

The problem is the Desktop sidebar information architecture after the remote threads are visible. "Sort by Projects" does not show Mac B's projects, while "Sort by Connections" shows Mac B's threads as a flat list without grouping them by their host project.

Expected behavior: the remote sidebar should support nested grouping such as Connection/Host → Project → Thread. Alternatively, Sort by Projects should include remote host projects with a visible host label, so local and remote project namespaces are not silently separated.

So this is related to #23933, #24271, and broader remote sidebar consistency, but it is specifically about Mac Desktop-to-Desktop remote host thread grouping, not a connection failure or iOS project picker mismatch.

Additional repro / confirmation on a newer Codex Desktop build.

Environment:

• Controller Mac: Codex Desktop 26.601.21317 / build 3511
• Platform: macOS / Darwin 25.3.0 arm64
• Remote host: another Mac running Codex Desktop, added under Settings > Connections > Control other devices
• Same ChatGPT account/workspace on both Macs

Observed behavior:

1. The remote Mac appears as connected in Settings > Connections > Control other devices.
2. In the main sidebar, Organize sidebar > By connection shows the remote Mac under Connections and lists remote chats/threads from that Mac.
3. Opening one of those remote chats works.
4. Switching the sidebar to Organize sidebar > By project does not create/show a project group for that remote Mac/project.
5. Switching to project grouping only shows local project groups, while the remote chat disappears from the normal project-organized view unless it is pinned.
6. Pinning the remote chat makes it visible in the pinned section, but that is a workaround for individual threads rather than a project browsing model.

Expected behavior:

• Either By connection should support nested grouping like Connection -> Project -> Thread, or By project should include remote-host projects with a visible host/connection label.
• A user controlling another Codex App host should be able to browse that host's projects, not only discover remote threads via By connection or keep individual chats visible by pinning them.

Actual behavior:

• Mac-to-Mac remote control exposes remote chats/threads, but the project organization mode does not appear to mirror or expose the connected host's project groups.
• The only reliable ways to find/use remote work are By connection or pinning specific remote chats.

This is distinct from Create new project -> Remote, which creates/opens a remote filesystem project. The issue here is browsing existing Codex App projects/threads from a connected Codex host.

Additional confirmation for the same issue, with a Mac controller connected to a Windows remote host.

Environment / diagnostics:

• Controller: Codex Desktop on macOS, bundled CLI/app-server 0.142.2.
• Remote host: Windows Codex Desktop via Settings > Connections > Control other devices, reported remote app-server 0.142.2.
• Remote connection reaches state=connected over websocket with no connection error in the controller logs.
• The controller receives remote thread/list responses successfully; refreshRecentConversationsFailed=false during reconnect recovery.
• Local controller state has remote-thread-summaries:<remote-host> populated with 19 remote threads across multiple distinct remote working directories, including one main Windows project path, one separate drive/root path, and several generated Codex workspace paths. Paths/host id intentionally redacted here.

Observed behavior:

1. In Control other devices, the Windows host appears connected.
2. When organizing the sidebar by host/connection, remote chats are visible as individual chats.
3. The same remote chats are not grouped under their remote projects.
4. Organizing by project does not expose the Windows host's project groups; it only behaves like local project grouping.

Why this is probably not a connection/indexing failure:

• The remote host is connected.
• Remote thread summaries are cached locally.
• Remote thread/list calls are succeeding.
• The missing piece appears to be the Desktop sidebar information architecture/state model: remote host threads are available, but the UI only exposes them as a flat connection-level list instead of Connection -> Project -> Thread or remote projects inside project grouping.

Expected behavior remains the same as the issue description: either By connection should support nested project grouping per host, or By project should include remote-host projects with a clear host label.

Additional confirmation from a mixed local + WSL + remote-host setup.

My Codex Desktop sidebar currently contains:

• local projects;
• multiple projects on a connected wsl-ubuntu environment;
• multiple projects on a macbook-air remote environment (currently offline);
• repeated project names such as local_ops, zenlayer, and openclaw_ops across different environments.

The current flat project list makes it difficult to scan and switch between projects. Host labels on the right help identify each row, but they do not provide usable hierarchy. I still have to manually drag/reorder projects, and that becomes cumbersome when several environments each contain several projects.

A collapsible two-level project navigator would solve this well:

Local
  ├─ local_ops
  └─ codex_workspace
wsl-ubuntu
  ├─ zenlayer
  ├─ gitlab_workspace
  ├─ local_ops
  └─ ...
macbook-air
  ├─ zenlayer
  ├─ personal
  ├─ openclaw_ops
  └─ ...

Ideally, each environment/connection would be independently collapsible, preserve its expanded state, show connection status at the group level, and contain its projects underneath. Threads can then expand under each project if needed: Connection → Project → Thread.

This would also disambiguate same-named projects on different hosts and reduce the need for manual sidebar ordering. My real-world sidebar screenshot shows exactly this mixed-environment case; I can provide it separately if maintainers need it.

Yes, I'd like this as well.

Additional confirmation on the current macOS app build.

Environment

• Controller: Codex Desktop 26.814.41407 (build 6720)
• Platform: Darwin 25.6.0 arm64 arm
• Remote host: connected Mac via Codex Remote Control

Observed

• The mobile Remote view correctly groups the same remote chats under their respective remote projects and shows the expected chats within each group.
• On Desktop, selecting Organize sidebar → By project does not reproduce that remote-project grouping. The remote work is either absent from the project-organized view or discoverable only as a flat recent/connection-level list.
• Consequently, Last updated ordering cannot match the mobile view because the remote project groups are missing from the Desktop grouping model.

This mobile-vs-Desktop comparison suggests that the remote thread/project association data exists and is available to clients; the gap appears to be in the Desktop sidebar grouping/presentation rather than remote thread retrieval.

Expected
Desktop should expose the same remote-project hierarchy as mobile, either as Connection → Project → Thread or by including remote projects in By project with a visible host label.

I would like this as well