[teamleaderleo]

Leo (2026-11-03): "it's so slow to open and close idk if there's some sort of threading issue but it's nigh instant for claude and codex so we nede to be at least as fast" and "the browser/tab opening animation still plays on the main pane before going". Earlier ask (#23032's title): "a link opened to the right appears in its split, never in the source pane first".

leo-named-fix. This is the daemon half; the app wiring follows in a second PR.

What

new-frontend-browser-tab takes an optional split ({direction, pane_id, split_id}, only with pane), behind the new capability frontend-browser-tab-split-v1, the same object new-conversation-tab takes under conversation-tab-split-v1. The tab is created directly in a new pane on that side of pane, in one pane.split commit: one pane-added delta whose pane holds only the tab, and the source pane never lists it. Today the app creates the tab in the source pane, waits for the store to list it, then sends a move to a new split: two daemon round trips, and the page shows in the source pane first.

Spec: cmux-tui/spec/commands.md and sdk-schema.json; SDK bindings regenerated (cmux-tui/bindings/codegen/generate.py --write), and the raw Rust client's keyed create names split as missing.

Carried commits

The three code commits are austinywang's from #23032 (authorship kept), cherry-picked onto current feat-cmux-next with only their daemon, spec and test parts; the generated bindings were regenerated instead of merged. The crate diff is line-for-line the same as #23032's. #23032's Swift side no longer applies on today's base (the browser opener moved to stand-in tabs), so the app wiring is rebuilt in the follow-up PR.

Tests

cmux-tui-core server::frontend_browser_split_tests (from #23032): one commit, one pane-added, no tab-added on the source pane, caller-minted ids, refusals (no pane, after with split, bad direction, a refused dock split creates no tab), pinned-dock-alone opens a column.

Risk

Low. Additive request field behind a new capability; a client that does not send split is unaffected. Rust only, no Swift.

Agent session: agent session

🤖 Generated with Claude Code

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Fixes new-frontend-browser-tab so a link opened to the right appears directly in its new split pane instead of first rendering in the source pane.

• Adds an optional split field ({direction, pane_id?, split_id?}, shared with new-conversation-tab) behind the frontend-browser-tab-split-v1 capability, so the tab is created in one pane.split commit with a single pane-added delta and is never listed by the source pane.
• Sending split without pane is refused, after is refused with split, and keyed creates fingerprint their split so a retry with a different split conflicts.
• Clients that don't send split are unaffected. This is the daemon half; the app wiring that sends it follows in a second PR, and older daemons keep the make-then-move path.

^{Written for commit 31ba863. Summary will update on new commits.}

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review 31ba863: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr32862 -f ref=lane/right-open-split-first -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4158055269401 (e5e182cf5b)
• cmux NEXT nightly 1.0.0-nightly.4158655642901 (38369c1a88)

[teamleaderleo]

Review (subagent claude-opus-5-5 medium): SHIP at 31ba863

Checked the split path of new-frontend-browser-tab against new-conversation-tab {split} (both use TabSplit / split_tab_pane_with_fields_as): validation, the caller-minted ids, pinned-dock-alone-v1, refusals that come before the browser record is registered, the keyed fingerprint (a different split under the same key is idempotency.conflict), and the advertised capability. Tests: cargo test -p cmux-tui-core --lib -- frontend_browser conversation_tab, 82 passed (fast checks run 41568171601); cargo check -p cmux-sdk passed.

Follow-ups:

• [follow-up] frontend_browser_split_tests.rs:165: no test covers a split that fails inside the mux after the record is registered (a pane_id already in use, a refused dock split).
• [follow-up] frontend_browser_history.rs:88: with split, activate:false is accepted and has no effect, while after is refused. Refuse it as well, or document it.

[teamleaderleo]

Review (codex gpt-6-astra high, router-review): SHIP at 31ba863
Visual verdict: no images; Leo tries the build

Reviewed split creation, idempotent retries, failure cleanup, and shared conversation-tab behavior; no actionable findings. Six SDK generation checks and 16 Python protocol tests passed (Rust tests ran separately on fast checks: 82 passed).

Follow-ups: none