[BUG] Desktop: clicking the app's own `claude://` links in chat output does nothing
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The macOS desktop app renders markdown links with the app's own claude:// scheme as regular clickable links (colored, underlined on hover), but clicking one does nothing – no navigation, no dialog, no OS dispatch. The URL itself is fine: open "claude://…" from Terminal opens the target directly, and pasting the link into Chrome bounces it via macOS back into the app, where it works. So the link works from anywhere except the app's own chat output.
Concrete case: Claude dug up an old session for me and answered with [Session title](claude://resume?session=<uuid>). Opening it meant copying the URL into a browser so the OS could hand it straight back to the same app.
What Should Happen?
Clicking a claude:// link should dispatch it like open does. Even limiting this to the app's own scheme would cover the case – #76505 proposes the same scoping for the VS Code extension's vscode://…open?session= links, to keep the prompt-injection surface unchanged.
Error Messages/Logs
None observed – the click produces no visible reaction, not even a confirmation dialog
Steps to Reproduce
- In the macOS desktop app, have Claude output a deep link in chat, e.g.
[Open session](claude://resume?session=<any session uuid>) - Hover the rendered link – it styles as clickable
- Click it – nothing happens
- Run
open "claude://resume?session=<same uuid>"in Terminal – the app opens that session, so URL and scheme handler both work
Claude Model
Other (Fable 5) – the behavior is in the app's renderer, independent of the model
Is this a regression?
No, this never worked
Last Working Version
n/a
Claude Code Version
2.1.217 (Claude Code), bundled in desktop app 1.24012.1
Platform
Anthropic API
Operating System
macOS 26.5.1
Terminal/Shell
Other – desktop app chat UI, no terminal involved
Additional Information
Prior desktop reports of this all died by automation, none were triaged by a human: #26952 (stale-closed, now locked – its closing note asks for a new issue referencing it, which this is), #51523 (stale-closed), #63204 (auto-closed as duplicate of the already closed #26952). The open #76505 (VS Code extension) and #68103 (FleetView statusline) are the same symptom on other surfaces, not duplicates.
The claude:// case is narrower than the earlier custom scheme reports: the product hands these links out itself (claude://resume, the /desktop flow) and the app registers the scheme, so there is no question of whether the target handler is safe or installed – the app would be dispatching to itself.