[FEATURE] Let an external app open a specific existing Claude Code chat in Claude Desktop (deep-link parity with VS Code's ?session=)

The outcome I'm after

A user has several Claude Code sessions going. An external macOS app lists them and shows which one is waiting on input. They click one, and that chat comes to the front in Claude Desktop.

That's the whole ask. Not a new session, not a message — just "take me back to the conversation I clicked on."

This works today on two of the three hosts. Desktop is the one where it matters most, and it's the one that can't.

| Host | Focus an existing session | How |
| --- | --- | --- |
| Terminal | ✅ | Resolve the session's TTY, activate that window/tab (OS-level) |
| VS Code | ✅ | vscode://anthropic.claude-code/open?session=<id> — documented, ungated |
| Claude Desktop | ❌ | no working route |

Terminal and VS Code sessions each get their own window, so OS-level activation gets close on its own. Desktop is one window with many chats — there is no external way to select among them, which is exactly why a link is the only mechanism that can work here.

What I verified (Claude Desktop 1.34493.1, macOS, 2026-08-25)

claude://code/{session-id} exists as a route but does not complete, for two independent reasons:

1. It's behind a feature gate. Firing a well-formed id logs:

claudeURLHandler: code session deep link gated off

2. The id namespace is unreachable from outside. The route validates the id against /^(cse|session)_/ — a server/bridge session id. Firing the id an external caller actually has produces:

claudeURLHandler: unrecognized code path { pathname: '/<uuid>' }

The only session identifier available outside the app is the CLI session id — the UUID that hooks emit as session_id, that claude --resume <id> accepts, and that names the transcript under ~/.claude/projects/. There is no documented way for an external process to obtain the corresponding cse_/session_ id.

These are independent. Enabling the gate alone would not help, because the id would still be rejected. That's the part I'd most like to flag — a fix that addresses only the gate would look shipped and still not work for any third-party caller.

The ask

Either of these, together with enabling the route:

1. Accept the CLI session id at claude://code/{session-id} — resolve it internally the way the app already maps between local and bridge session ids, or
2. Document a supported way for an external process to obtain the bridge id for a running session.

Plus enabling the gate, which is necessary for either.

Why this is a small ask

vscode://anthropic.claude-code/open?session=<id> already does exactly this, from any external caller, with no gate and no special entitlement — and it takes the CLI session id, the one callers actually have. The behaviour is documented: "If the session is already open in a tab, that tab is focused." Desktop parity with that route is the entire request.

Scope / privacy

Local only. No data is requested from Anthropic — just a "focus this session" affordance. The caller already holds the session id from the hook payload it received on its own machine.

Related

• #54614 — this was raised in that thread, but its title scoped it to opening a new session in a folder (claude://code/new?folder=, which shipped and works well). The existing-session ask was thread drift and was closed along with the title's ask, so I'm re-filing it narrowly rather than continuing in a closed issue.
• #81202 — claude://cowork/{session-id}, the same request for Cowork, still open.
• #89511 — the VS Code route's sidebar limitation (adjacent, not blocking this).