Desktop app: embedded browser panel silently drops custom-scheme deep links (obsidian:// etc.)

Feature request

The desktop app's embedded browser panel ("open links in browser panel") does not process custom-scheme deep links: an http(s) URL that redirects (308) to a custom scheme such as obsidian:// navigates in the panel but the handoff to the OS protocol handler never fires. The click is silently consumed — the panel just keeps showing whatever it last displayed, with no error and no external app launch.

Request: when a navigation in the embedded panel resolves to a non-http(s) scheme, hand it off to the OS (same behavior as every desktop browser), or at minimum surface a prompt/fallback to open externally.

Environment

• Claude desktop app 1.30096.1, Windows 11
• "Open links in browser panel" enabled (appears to be the default)

Reproduction

1. Enable "open links in browser panel".
2. In any chat, have Claude output a link that redirects to a custom scheme. Public example (redirects to obsidian://open?...): https://obsid.net/?vault=SomeVault&file=SomeNote — any self-hosted redirector (e.g. Caddy redir /o obsidian://open?{query} 308) reproduces identically.
3. Click the link.

Expected: the redirect resolves to obsidian://… and the OS opens Obsidian (this is what happens when the same link is opened in any system browser, and what happens with the panel setting disabled).

Actual: nothing visible happens; the panel opens/fronts with its previous content. No prompt, no navigation, no external app.

Notes

• With the setting disabled, the same links work correctly via the system browser, so this is purely about the embedded panel's scheme handling.
• Related but distinct: #81515 asks for clicks to default to the system browser. This request is complementary — if the panel does take the click, deep links should still complete. Both together would make the panel safe to leave enabled for workflows built on app-handoff links (Obsidian, editors, etc.).
• Real-world context: automation that emits https://…/o?… → obsidian:// links (so the same link works on desktop, Android, and in notification services that only accept http(s) URLs). These links all dead-end in the panel today.