#23902 cmux-next: Cmd-clicked link opens straight into the split (one animation)

Summary

When you Cmd-click a link and nothing is on the right, cmux-next opens it in a new split. The link's tab is meant to open unselected in the pane you clicked and then move into the split. The background flag never reached the daemon, though. new-frontend-browser-tab was sent with the default activate: true, so the daemon selected the tab in the clicked pane, which was the first animation. Then the move created the split, which was the second.

PaneBrowserTabOpener now passes activate: !background. The off-screen opener path in BrowserPageRequests does too. The clicked pane keeps showing its own tab, and only the split animates. This applies to every background daemon browser open that goes through PaneBrowserTabOpener, not only Cmd-click into a split: Ctrl/middle-click background tabs, background bookmark and hit-test opens, agent and CLI opens while you are in that pane, and the links after the first in a multi-link workspace open now stay unselected, as their call sites already documented. Placed opens (split, new column, beside the dock, dock chat, agent beside a chat) still end selected: their move or reveal selects the tab.

Every daemon that has frontend-browser-activate-v1 supports this, and an older daemon ignores the field as before (BrowserTabService.create).

Testing

Regression test: CmdClickOpensRightTests.aLinkBoundForANewSplitNeverTakesTheClickedPane. It does a Cmd-click openWeb with linkPlacement splitRight and no pane on the right, and it requires the daemon request to carry activate == false.

Command: cmux-ci run --class light --script scripts/ci/package-test-lane.sh --arg suite --arg Packages/macOS/CmuxNext --arg CmdClickOpensRightTests (Xcode 26.6). It runs at the test commit (red) and at the fix commit (green). Results follow in a comment. The test calls openWeb without cmdClick, which the base removed in 0d673448d7b1.

Observed / Not run

• Observed: the prepush gate reported no new violations.
• Not run: no tagged-app dogfood or capture yet. The change is the daemon request flag only; no new UI was added.

Changelog

Fixed: Cmd-clicking a link that opens in a new split no longer shows it in the clicked pane first, and background tab opens no longer take over the pane they open in.

No capture: no new UI. The fix removes the extra in-pane step of an existing animation; dogfood on the nightly.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes Cmd-clicked links bound for a new split no longer taking over the clicked pane first — they now open straight into the split in one animation. Passing activate: !background on the daemon tab request keeps the clicked pane's own tab selected, so only the split animates.

• PaneBrowserTabOpener and the off-screen opener path in BrowserPageRequests both use the flag.
• Daemons without frontend-browser-activate-v1 ignore the field as before.
• Adds a regression test asserting the split-bound Cmd-click sends activate == false; the test fails instead of hanging when the open is refused.