[FEATURE] Un-gate claude://code/continue?session=<local_id> — validation and lookup are already implemented

Summary

claude://code/continue?session=<local_session_id> already contains a complete implementation for focusing a specific desktop session — parameter validation, exact-ID lookup, and route resolution are all present in the shipped app — but the handler returns early behind a feature gate, so the link only brings the app to the foreground and stays on whatever session was last focused.

Please consider enabling this path (or exposing an equivalent documented one).

Use case

A session finishes work (or a scheduled reminder fires) and pushes a message to my phone. I have a dozen sessions open. The notification tells me something happened, but not which session said it — so I have to hunt through the sidebar.

The fix is for the notification to carry a "return to the sender session" link. That works end to end today except for the final hop.

What I found

Environment: Claude Desktop 1.37937.3, Claude Code 2.1.150, macOS 26.5.2.

1. claude://code/continue?session=<id> — validation and lookup are implemented, but gated

The URL handler validates the parameter:

function bBt(e){ return e === `last` || (e !== null && yBt.test(e)) }
// yBt = /^local_[A-Za-z0-9-]{1,64}$/

A local_… session ID passes this check. The resolver does an exact match and produces a route:

async function SBt(e){
  const t = await $j();
  await t.waitForSessionsLoaded();
  const n = (await t.getAllSessions()).filter(s => !s.isArchived);
  const r = e === `last`
    ? n.sort((a,b) => (b.lastActivityAt ?? 0) - (a.lastActivityAt ?? 0))[0]
    : n.find(s => s.sessionId === e);          // <- exact ID match already supported
  return r ? t.getSessionRoute(r.sessionId) : undefined;
}

But the entry point returns before any of that runs:

async function xBt(e,t,n,r,i){
  const a = wM();
  if (!await Mzt()) { P.info(`claudeURLHandler: code entry deep link gated off`); return }
  ...
}

Observed in ~/Library/Logs/Claude/main.log on every click:

claudeURLHandler: code entry deep link gated off

Result: the app comes to the foreground but does not switch sessions. From a user's point of view the link looks broken, with no error shown.

2. claude://resume?session=<cli_session_uuid> works, but duplicates instead of focusing

This path is not gated and does fire:

Resume deep link: importing CLI session 6df6752e-…

It calls importCliSession(), which creates a new session entry from the CLI transcript. The original desktop session stays where it is, and the sidebar now has two entries with the same conversation. Usable as a workaround, but it pollutes the session list every time.

3. The documented deep link cannot do this

Launch sessions from links covers claude-cli://open, registered by the CLI, which accepts only q, cwd, and repo. It starts a new terminal session; there is no parameter for resuming an existing one.

Why this issue rather than a +1 on the existing ones

#50345 (closed) asked for exactly this and reported that --resume <uuid> and various schemes were ignored. #81202 asks for the Cowork equivalent.

The new information here is that this is not a missing feature — it is a disabled one. The ID format is accepted, the lookup is exact, and the route is computed. Only Mzt() stands between the current behaviour and the desired one.

Request

Any of these would solve it:

1. Enable the gate for claude://code/continue?session=<local_session_id>.
2. Make claude://resume focus an existing session when the transcript is already imported, instead of importing a duplicate.
3. Document a supported equivalent, so integrations do not have to rely on internals.

Workaround in the meantime

A local HTTP redirect service maps a short code to the session ID and 302s to the claude:// URL, and the notification includes the session's title so the right sidebar entry can at least be identified by name. Everything works up to the final hop.