Repository navigation
feat(links): route BROWSER through wmux - #340
Merged
Merged
Conversation
amirlehmam
added a commit
that referenced
this pull request
Oct 24, 2026
The checked-in CLI copy lacked the new `wmux open` verb, which fails the release build's verify:resources step. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Closes #339.
Routes links opened by a CLI inside a WSL pane through wmux's existing link policy. Today OpenCode v2 captures the mouse and opens plain clicks itself with
open; on WSL that reaches PowerShell and the system browser, so the panel only has Ctrl+click. Claude/Codex panes and shell output already open in the panel.wmux open <url>— new CLI verb, sendslink.openover the pipe and calls the renderer'sopenInWmuxBrowser(). It does not usewmux browser open: that resolves the caller's agent-bound browser (Concurrent agents share a single browser window, causing interference #62) and waits for CDP navigation. It returns after dispatch.link.open— v2 bridge method. The URL is JSON-encoded into theexecuteJavaScriptexpression, and the renderer refuses anything but http(s).wmux-open-url— a$BROWSERshim incli-bin.PtyManagersetsBROWSER=wmux-open-urlfor WSL panes only and addsBROWSER/uto WSLENV. The value is a bare name because BROWSER parsers split on whitespace and the install path can contain spaces. If wmux is unreachable, the shim hands the URL towslview/explorer.exeinstead of leaving a dead click.BROWSERthey had; the shim is POSIX-only.This is deliberately not
"mouse": falsein OpenCode: OpenCode stays on the alternate screen and does not scroll its transcript on arrows, so that would break wheel/touch (#245/#267). Mouse capture,wheelForwardandtouchPanGainare untouched. #280's plain-click rule is untouched too; the fix is to route the app's own opener.Codex gets the behaviour immediately (its Rust opener honours
$BROWSER). OpenCode needs the paired one-file change: anomalyco/opencode#58526.Type of change
Tests
npx vitest run tests/unit/open-link.test.ts tests/unit/link-open-bridge.test.ts \ tests/unit/cli-open.test.ts tests/unit/browser-env.test.ts \ tests/unit/cli-bin-shims.test.ts tests/unit/terminal-links.test.ts # 44 passed, 4 skipped npm run typecheck npm run build:mainNew coverage: renderer URL gate and delegation, JSON escaping of the bridge URL,
wmux openargument rules, WSL-onlyBROWSERselection and WSLENV entry, and the shim forwardingopen <url>to the CLI.The live Windows/WSL matrix (wheel, touch, Codex and patched OpenCode clicks, both destination settings) is not runnable in this Linux container; it needs a manual pass before merge.