Desktop: 'Open in app' link preference is ignored for localhost/.local URLs
Description
In the Claude Code desktop app (macOS), the link-open preference "Open in app" (open links shared by Claude as tabs in the built-in Browser pane) works for external URLs but is silently ignored for local-host URLs — localhost:<port> and *.local vhosts always open in the system default browser.
For a development tool this inverts the most useful case: links to the app under development (dev servers, Mailpit, local vhosts) are exactly the ones you want in the Browser pane, where Claude can see and act on the page.
Steps to reproduce
- Settings → Claude Code → Browser: enable "Browser tools" and "Open links in browser".
- Click a link shared by Claude in the chat and choose "Open in app" in the chooser dialog ("Where should links open?").
- Click a link to
https://example.com→ ✅ opens in the Browser pane, as configured. - Click a link to
http://neverssl.com(plain-http external) → ✅ also opens in the Browser pane, so the rule is not about the URL scheme. - Click a link to
http://localhost:8125orhttp://myapp.local→ ❌ opens in the system default browser, no chooser, preference ignored.
Restarting the app does not change the behavior. The persisted preference is correct — ~/Library/Application Support/Claude/claude_desktop_config.json shows:
preferences.epitaxyPrefs.epitaxy-transcript-links-in-preview = true
preferences.epitaxyPrefs.epitaxy-transcript-links-chooser-seen = true
The Browser pane itself handles these local URLs fine: when Claude navigates to the same localhost/.local URLs via its browser tools, the pages load normally in the pane (local servers don't even require per-site approval). Only user link-clicks are routed away.
Expected
Links to local hosts follow the same "Open in app" preference as external links — or, if routing local URLs to the system browser is intentional, the chooser/setting description should say so and ideally offer a per-host override.
Environment
- Claude Code desktop app (macOS, Darwin 25.4.0), app version 2.1.x (July 2026)
- Preference chooser answered "Open in app"; behavior confirmed after full app restart
- Cmd+click (explicit "open in system browser") works as documented