Codex Desktop deep links silently fail for existing SSH remote tasks

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

26.715.31925 (build 5551)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

codex://threads/<thread-id> correctly opens existing local tasks. For a task owned by a configured SSH remote host, clicking the same canonical link brings Codex Desktop to the foreground but does not navigate to the task and displays no error.

The remote task still exists, appears in Codex's sidebar/search, and opens normally when selected through the UI. Codex's local global state also already associates the task ID with the correct remote project and hostId.

The current documentation describes this route as opening a local chat, so remote support may currently be an unimplemented case. However, silently doing nothing is particularly confusing for external task indexes such as Obsidian, Jira, or internal engineering dashboards.

What steps can reproduce the bug?

1. Configure and connect a Codex-managed SSH host.
2. Create or open a task whose authoritative app server is on that host.
3. Confirm the task is visible and openable in Codex Desktop.
4. Obtain its technical task ID.
5. Open codex://threads/<remote-thread-id>.
6. Observe that Codex Desktop comes to the foreground but remains on the current screen.

The equivalent URL for a local task navigates correctly.

Adding ?hostId=<remote-host-id> does not help.

What is the expected behavior?

Codex Desktop should resolve the task's existing project/host assignment and open it through the corresponding remote app-server connection.

An explicit host parameter could also be supported, for example:

codex://threads/<thread-id>?hostId=<encoded-host-id>

If the assigned host is disconnected, Codex should navigate to an informative unavailable/reconnect state instead of silently ignoring the link.

Additional information

Inspection of the installed application indicates that:

• The threads/<id> deep-link parser produces a local-conversation route.
• Dispatch checks the task exclusively through the local app-server connection.
• A hostId query parameter is currently ignored.
• The desktop global state already contains the correct remote project and host assignment for the affected task.

This suggests the route could first resolve the existing task assignment, select the corresponding app-server connection, and then perform the current existence check and navigation.

Related but distinct issues:

• #33359 - remote pinned-thread hydration routed to the local app server
• #29726 - SSH deep links for connections and creating new tasks

The official deep-link documentation currently characterizes existing-task links as local-chat links: https://learn.chatgpt.com/docs/reference/commands#deep-links