macOS Remote Control threads are reachable by ID but not discoverable in the desktop UI

No files or tests are named in the report. Start by reproducing the connected-host state, then trace the existing remote thread enumeration and direct-navigation paths described here. Done means the desktop UI exposes a connected host and lets users browse its projects and tasks without knowing a thread ID.

What version of the Codex App are you using?

Codex macOS app 26.715.72359 (5718) on the controller MacBook.

The remote host is another Mac running Codex Desktop (a Mac mini). Its exact app build was not captured.

What platform is your computer?

• Controller: MacBook, macOS 26.5.2 (25F84), arm64
• Remote host: Mac mini connected through Codex Remote Control
• Both devices are signed in to the same Codex/ChatGPT account

What issue are you seeing?

Remote Control is connected and the MacBook can communicate with the Mac mini, but Codex Desktop provides no user-facing way to browse and open the Mac mini's existing tasks.

This is not a connection, authentication, Git, or Handoff failure:

• Remote-host thread enumeration returns tasks from the Mac mini.
• If a remote thread ID is already known, direct navigation opens the task successfully.
• The app then sends thread/read and thread/resume to the remote-control host, confirming that the remote task is valid and reachable.
• Git-backed Handoff between the two Macs also works independently.

However, in the normal MacBook desktop UI there is no visible Mac-mini.local host section, remote project tree, or remote task list from which the user can discover and open those tasks. Without an already-known thread ID or programmatic navigation, the remote conversations are effectively inaccessible.

The missing layer appears to be desktop discovery/navigation for Remote Control tasks, rather than remote transport or task persistence.

What steps can reproduce the bug?

1. Sign in to Codex Desktop on two Macs using the same account.
2. Enable Remote Control on a Mac mini and connect to it from a MacBook.
3. Create several normal Codex tasks on the Mac mini.
4. Confirm that Remote Control is connected.
5. On the MacBook, inspect the normal sidebar and project/task navigation.
6. Observe that there is no browsable host/project/task hierarchy for the Mac mini and no visible list of its existing tasks.
7. Independently enumerate threads for the connected remote host: the Mac mini tasks are returned.
8. Navigate directly to one of those remote thread IDs: the task opens and resumes successfully on the remote host.

What is the expected behavior?

Once a Remote Control host is connected, Codex Desktop should provide a user-facing way to browse and open that host's tasks.

A suitable UI could be:

Connection / Host
  -> Project
      -> Task

At minimum, the desktop app should provide:

• a visible connected-host selector;
• a remote task list or filter;
• project/task grouping for each host;
• clear host ownership on opened tasks;
• title-based discovery without requiring a thread ID.

What is the actual behavior?

The remote host and its tasks exist and are reachable below the UI layer, but the user has no discoverable desktop route to them. The only confirmed way to open one is to already know its ID and invoke a direct navigation path.

This makes Remote Control appear nonfunctional even though the underlying connection and remote task APIs are working.

Additional information

This is closely related to:

• #31407 — remote projects missing from the Mac sidebar, although that report says remote threads are already visible;
• #24295 — request for Connection -> Project -> Thread grouping;
• #27284 — remote threads exist but are missing from a desktop project view.

The distinguishing symptom here is that the remote threads are not available through any user-facing remote task browser on the controller Mac; they are only confirmed through underlying enumeration and direct navigation by ID.

Sanitized desktop logs can be provided if maintainers specify which events or files would be most useful.