[FEATURE] Desktop Browser pane: open a link in a new tab (Ctrl+click is already bound to the external browser)

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 5, 2026

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?

The Browser pane is already a tabbed browser, and the docs pitch it for exactly the workflow that needs tabs: "open documentation, issue trackers, or any other site next to your running app."

But clicking a link inside the pane always replaces the current tab, and there is no way to open it in a new one. Reading docs or an issue tracker means constantly navigating forward into a link and then back out, losing your place in the page you came from. Any browsing that branches — a docs index, a list of issues, search results — is far more painful than it needs to be.

The usual escape hatch is unavailable, because the modifier is already bound to something else: Ctrl+click opens the link in the external default browser, which is the documented behaviour for chat links and applies in the pane too. So the one gesture every browser uses for "open in a new tab" is taken by "leave the app entirely" — the opposite of what a user branching through docs wants.

Proposed Solution

Provide a way to open a link in a new tab within the Browser pane. Any of these would solve it:

  • Middle-click — the other universal gesture, and currently unassigned as far as I can tell.
  • Ctrl+Shift+click — keeps Ctrl+click as "external browser" and adds the in-pane variant next to it.
  • A context-menu item on links: "Open in new tab" alongside whatever else the pane offers.
  • A setting in Settings → Claude Code: open links from the pane in a new tab by default rather than replacing.

A context-menu entry is probably the most discoverable, since it does not require guessing a modifier; a gesture is the one people will reach for reflexively.

Alternatives Considered

  • Ctrl+click — opens the system browser, which defeats the purpose of browsing beside the app and splits attention across two windows.
  • Opening a second pane tab manually and pasting the URL — works, but requires copying the target URL out of the page first, which is several steps for something that is one gesture everywhere else.
  • Using the Chrome extension instead — different tool with a different purpose (it acts in your logged-in profile); the pane deliberately uses a clean profile, and for reading documentation that separation is the right one. Switching tools to get tabs is a poor trade.

Environment

  • Claude Desktop: 1.24012.11 (Linux beta, apt)
  • Linux Mint 22.3 (Ubuntu 24.04 base), x86_64, X11, Cinnamon
  • Not platform-specific — the behaviour is a property of the Browser pane

View original on GitHub ↗