Repository navigation
Links: route OpenCode's own link clicks into the wmux panel #339
Description
What are you trying to do?
Click a link in an OpenCode v2 pane in wmux (WSL) and have it open in the wmux browser panel, like Claude Code panes and shell output. Today plain click opens the system browser and Ctrl+click is the only route to the panel.
This is the other side of #280: while an app captures the mouse, the plain click belongs to the app. The fix is to make that app's open go through wmux.
What would you like wmux to do?
Route app-opened links through wmux: set BROWSER=wmux-open-url for WSL panes, ship that shim in cli-bin, and add wmux open <url> that calls the renderer's openInWmuxBrowser() so Settings → Browser → Links still decides panel vs system browser. The verb must not wait for CDP, and the shim must fall back to the system browser if wmux is unreachable.
Codex gets this immediately (its Rust open path already honours $BROWSER). OpenCode needs a one-file change upstream: anomalyco/opencode#58526
What do you do today instead?
"mouse": falsein OpenCode'scli.json. Breaks wheel/touch scrolling: OpenCode stays on the alternate screen and arrows are composer history, not transcript scroll.- Swallow the click in xterm. Fragile, and reopens bug: one click on a link in an OpenCode v2 pane opens both the system browser and the wmux panel #280's double-open class.
wmux browser open. Routes to the agent-bound browser (Concurrent agents share a single browser window, causing interference #62) and waits for CDP navigation.
Activity
amirlehmam commentedon Oct 24, 2026
Shipped in v2.40.0. Thanks for the detailed report!