Repository navigation
bug: one click on a link in an OpenCode v2 pane opens both the system browser and the wmux panel #280
Description
What happens
Plain-clicking an http(s) link in an OpenCode v2 pane opens it twice: once in the system default browser, and once in the wmux browser panel. Exactly one open is expected.
Only OpenCode panes are affected, because the v2 TUI handles plain clicks on links itself. Shell output and other panes keep the documented behaviour (click opens the panel).
Discriminator: Ctrl+click on the same link produces a single open (wmux handles it; OpenCode deliberately ignores modified clicks and leaves them to the terminal). URLs in plain shell output open only the panel, unchanged.
Steps to reproduce
- Run
opencode(v2 TUI, v2.0.27 here) in a wmux pane. - Have a URL in the transcript (any answer that prints one).
- Plain left-click the URL.
Result: the system browser opens the URL and the wmux browser panel opens/navigates to it in the same gesture.
Control: plain-click a URL in shell output in the same terminal. Only the panel opens, which isolates the second opener to the app.
wmux version
2.20.0
Windows version
Windows 11
Anything else
Two independent openers fire on one click; neither can see the other.
OpenCode v2 TUI (sst/opencode, packages/tui):
src/app.tsx: the rootonMouseUpcallsclickedLink(renderer, event)and thenopenUrl(url);openUrllives inpackages/tui/src/ui/link.tsxand uses theopenpackage, so it launches in the system default browser.src/ui/link.tsxdocuments the intended split: plain clicks open the URL "in the default browser"; modified clicks (Ctrl/Alt/Shift) are skipped, "left to the terminal's own hyperlink handling".- Mouse reporting is enabled, so the app receives the click. Nothing about the click is announced to the terminal; the terminal just also sees it.
wmux:
src/renderer/hooks/useTerminal.ts:876,904: xterm's OSC 8linkHandlerandWebLinksAddonboth route toactivateTerminalLink(src/renderer/utils/terminal-links.ts:5), which callsopenInWmuxBrowser(src/renderer/utils/open-in-browser.ts:37) and opens the panel by default (openLinksExternally: false).- xterm 6.0.0's
Linkifieractivates a link on a plain mouseup with no modifier requirement and no check for whether the foreground app owns the mouse. It fires while the app is being sent the same click. The#250dedup guard only collapses duplicate activations inside xterm (stacked providers, same MouseEvent), so the app's own open is invisible to it.
Why I think this is a wmux issue: mainstream terminals gate link opening behind a modifier (Windows Terminal Ctrl+click, VS Code Ctrl/Cmd+click, iTerm2 Cmd+click, kitty Ctrl+Shift+click), because a plain click belongs to an app that has captured the mouse. wmux is the outlier: it opens hyperlinks on plain clicks unconditionally, which any mouse-capturing TUI with its own link handling will trip over. OpenCode v2 is the first such TUI I hit; the trigger was the OpenCode update, not a wmux change.
Possible direction (not prescribing one): skip the unmodified-click activation when terminal.modes.mouseTrackingMode !== 'none' (public xterm 6.0.0 API), so plain clicks stay with the app and shell output keeps click-to-panel. Open question: in those panes, what should Ctrl/Cmd+click do? Today's #201 inversion (external browser under the default setting) or the browserPrefs default (panel), so the panel stays reachable there? Happy to open a PR once that's settled.
Activity
fix(terminal): a plain link click belongs to an app that captured the…
amirlehmam commentedon Oct 14, 2026
Thanks, the analysis was right all the way through. Fixed in 2.21.0, along the lines you suggested.
Plain click: when
terminal.modes.mouseTrackingMode !== 'none', wmux no longer activates a link on an unmodified click. The click belongs to the app, which in OpenCode v2 opens one browser. Shell output keeps click-to-panel. The mode is read at click time rather than when the pane is created, because OpenCode turns tracking on when it starts and off when it exits, and the pane outlives it.Your open question, Ctrl/Cmd+click in a mouse-tracking pane: it opens the configured destination and does not invert it. Under #201, Ctrl inverts because a plain click already reaches the default destination. In a pane where the app owns the plain click, Ctrl is the only way to reach wmux at all. If it still inverted, the panel (the out-of-the-box default) would be unreachable from every such pane. In OpenCode both gestures would also land in the system browser. So in OpenCode:
openLinksExternallyoff (default)Both the OSC 8 handler and the WebLinksAddon go through the same decision,
linkClickTargetinutils/terminal-links.ts. Every cell is covered by a test. Settings → Browser now explains this next to the existing hint.