[BUG] Desktop: PR links always open in the internal Browser pane while every other external link opens in the default browser

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single report

What's Wrong?

GitHub pull request links open in the Desktop's internal Browser pane, while every other external link in the same chat opens in the system default browser. Jira issue links, documentation links, and plain URLs all go to the default browser; only PR links are captured by the pane.

There is no setting to change that. The docs describe the general behaviour — "When you click an external link in the chat, a chooser offers Open in app to use the Browser pane or Default browser to use your own" — but PR links bypass the chooser entirely and go straight to the pane.

For anyone who works with a real browser (logged-in GitHub session, extensions, tabs, existing window layout), landing in a clean-profile pane instead is a dead end: the pane deliberately uses a separate profile with none of your logins, so a PR opened there is not the PR you can review.

What Should Happen?

PR links should follow the same rule as every other external link — either the chooser, or whatever default the user has settled on. Failing that, a per-link-type setting, or simply including PR links in the "open external links in the default browser" behaviour.

Reproduction

1. In a Desktop Code session, have Claude output a Jira issue URL and a GitHub PR URL.
2. Click the Jira link — it opens in the system default browser.
3. Click the PR link — it opens in the internal Browser pane instead.

The only workaround is far too blunt

The single lever that forces PR links out to the default browser is the disableBrowserExternalNavigation managed setting:

{ "disableBrowserExternalNavigation": true }

That works — PR links now open in the default browser — but the cost is out of proportion to the goal:

• It requires root, since managed settings live in /etc/claude-code/managed-settings.json on Linux. This is an organization-policy mechanism being used to change a personal link preference.
• It turns off all external browsing in the pane, for the user and for Claude. Claude can no longer read or act on any external page, which is a genuinely useful capability being traded away to fix link routing.
• It is invisible and non-obvious: nothing in the UI hints that link routing is what this setting controls.

A user who just wants "PR links in my normal browser" has to disable a whole feature area, with sudo, to get it.

Notes from looking at the bundle

app.asar has no configurable routing hook — no openLinkInApp, shouldOpenInApp, openInBrowserPane, or isPullRequestUrl. The pane path is the internal openExternalLinkInPreview on the Launch interface. So the PR-link behaviour looks hardcoded rather than driven by a preference that is merely undocumented.

PR monitoring itself is unaffected by the workaround, since it polls through the gh CLI rather than the pane — so the pane capture does not appear to be required for the PR features to work.

Environment

• Claude Desktop: 1.24012.11 (Linux beta, apt)
• Embedded CLI: 2.1.219
• Linux Mint 22.3 (Ubuntu 24.04 base), x86_64, X11, Cinnamon