[FEATURE] Desktop: remember the link destination and reuse the open Browser pane, instead of a chooser on every external link

Preflight Checklist

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

What Problem Does This Solve?

Every external link clicked in the chat pops a chooser — Open in app or Default browser — and the answer is never remembered. For someone who has decided they want links in the Browser pane, that is a modal decision on every single link, forever, to give the same answer every time.

There is no setting for it. The app bundle has no linkBehavior, openLinksIn, alwaysOpenIn, defaultLinkTarget or equivalent key, and the docs describe the chooser as the only path.

The friction is sharpest once the Browser pane is already open. At that point the user has visibly committed to browsing inside the app, and the chooser is asking a question whose answer is on screen. The natural behaviour is the one the terminal pane already has: one pane, reused. You do not get asked where each command should run.

Proposed Solution

Two parts, useful independently:

1. A remembered default for link destination. Either a "don't ask again" affordance on the chooser itself, or a setting under Settings → Claude Code: open external links in the Browser pane / in the default browser / ask each time.

1. Reuse the open Browser pane. When a Browser pane already exists in the session, send the link there instead of prompting — matching how the terminal pane is reused rather than spawned per command.

Relationship to #84322

#84322 asks for the ability to open a link in a new tab within the pane instead of replacing the current one. The two compose: this issue is about getting the link into the pane without being asked, that one is about where it lands once it is there. Neither substitutes for the other, and both are about giving the pane the tab semantics people already expect from a tabbed browser.

Alternatives Considered

• disableBrowserExternalNavigation managed setting — does the exact opposite (forces everything out to the system browser), needs root, and disables Claude's own access to external pages. I ran with it for two weeks for the inverse use case; it is a blunt instrument in either direction.
• Ctrl+click — documented as "open in the system browser directly", so it is the escape hatch for the other destination, not this one. There is no modifier that means "app, and stop asking".

Environment

• Claude Desktop: 1.32352.1 (Linux beta, apt)
• Not platform-specific