Repository navigation
cmux NEXT model picker: every harness its own tab again (claude-sr2 models back), and Claude Code gets full model ids - #27692
austinywang wants to merge 7 commits into
Conversation
…ode full model ids #26969 folded every harness that draws the Claude or Codex mark into one rail tab. A custom harness such as claude-sr2 (its own profile with icon = "claude") lost its tab and its model list, and Claude Code (acp), Codex (work) and the other launch configurations became launch-only rows. Restore the per-harness rail the picker had before (each harness and launch configuration its own tab with its own models); the later density, search, provider and checkmark fixes stay. acpmux: a chat started or switched with a versioned family name (opus-5-5) failed every turn because Claude Code sent it to the API as typed. The Claude stdio translator now hands Claude Code the full id (claude-opus-5-5) at spawn, on session/set_model and on the model config option. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
Passes: CI passes on CI passes on Written by web and size checks: green Gallery before/after for
States
Pick other states with a |
|
Found 8 test failures on Blacksmith runners: Failures
|
|
Correctness review (subagent, head 9089506), and the resolution of each finding:
Follow-up is tracked in #27723. A Claude agent chat takes over to turn this into a proper revert of #26969. |
…models Make the webview side equivalent to `git revert 7f7d931`: the launch-profiles gallery states it added go, and railByHarness keeps its pre-#26969 comment. A launch configuration that is not the running harness (claude-sr2, Claude (work), Codex (work)) was a launch-only tab with no models, before and after #26969. When its own catalog entry lists models, it is now an ordinary rail tab that shows them; picking one starts the chat on that harness, as picking a Codex model does. An entry with no models still launches from its tab. In a started chat every other tab still forks. Format model-menu-started-chat-fork.test.tsx for vp fmt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…-per-harness-model-picker
Review follow-ups: a launch entry whose probe failed (every row disabled) keeps its one-click launch tab, the profile branch of railByHarness gets a test (a second launch entry of one family lists its own models and starts itself), and the started-chat rail drops a duplicate return. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Correctness review (subagent), head 51f9ccc, and the resolution of each finding. Follow-ups are in c329f8d. Verdict: no blockers. The revert of #26969 is complete (nothing in webviews refers to
Earlier review (head 9089506): the My own check of the exact diff against |
…-per-harness-model-picker
|
Review (codex gpt-6.1-sol high fast, review-router; started by the backlog lander): BLOCK at a327a7c BLOCK
|
|
Review (codex gpt-6-astra high, fast, independent, via review-router): BLOCK at a327a7c
(Posted by the coordinator for awareness; the reviewing lane's broker can't comment on this PR. Nobody else pushes to this branch.) |
|
Carried in #28050: your three commits, with your authorship, cherry-picked onto the feat-cmux-next tip, plus one fix for the exact-head review finding above (a launch entry whose probe failed keeps its launch tab: QuickFamily carries HarnessChoice.unavailable), with a test. It lands there; this PR stays yours to close. |
…feat-cmux-next tip (#28261) * ci(next): the tip suite dispatcher also runs the daemon suite on the feat-cmux-next tip A feat-cmux-next push never runs daemon-test, so the base had no "cmux-next daemon tests" verdict for hours and base_red_excuse.py could not compare any pull request's daemon red with it (#27692, #27868). The tip suite dispatcher now has a daemon leg beside the Swift one (a matrix over the two suites): a tip_daemon_suite run of cmux-next.yml, routed on the router's daemon tier since the last daemon verdict, and dispatched regardless once the tip is 20 landings past it. Runs are told apart by name and tested commit, so a same-tree run that tests a recorded sha after the tip moved still counts. Before feat-cmux-next's cmux-next.yml takes the input, the daemon dispatch warns instead of failing the tick. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): a deferred daemon suite run is pending, and only the unknown-input 422 is a warning Review of #28261: - A tip daemon suite run whose daemon-test was skipped (its tree was still publishing) was a no-verdict run, so the next tick dispatched the same sha again and two same-tree runs could follow. It is now pending for 90 minutes (DEFERRED_GRACE_MS): its same-tree run, named for the same sha, then gives the verdict. Past the grace it is a lost run and is retried. The Swift suite has no deferred state. - Only GitHub's `Unexpected inputs provided: [...tip_daemon_suite...]` 422 is a warning; any other 422, and every Swift refusal, fails the tick. - Tests: the deferred run, its same-tree run in flight and its verdict, the grace, the 422 messages, and the feat-cmux-next router printing swift= and daemon=. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(rescue): a failed tip daemon suite run wakes a rescue when it completes Review of #28261: the owned-pool rescue woke on a failed `cmux-next tip Swift suite` dispatch but not on the new daemon suite's, so a runner refusal of its daemon test waited for the two-hourly sweeper and the base had no daemon-test verdict meanwhile. The `completed` wake now matches `cmux-next tip daemon suite` too (completed_target already takes any cmux-next dispatch), with tests. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): the daemon suite's 20-landing floor counts from its newest verdict Review of #28261: the floor counted from the routing base (the last green), so a red periodic run after it made every later tick dispatch again once 20 landings had passed since the green. It now counts from the newest daemon verdict of either kind (one more compare when that is not the green); routing still diffs from the last green. Tests: a red verdict 1 landing back holds the floor, 20 past it dispatches. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
…8283) * ci(next): a tip daemon suite gives the base a daemon-test verdict A feat-cmux-next push never runs daemon-test: its same-tree run has origin push, and a dispatch's tree wait marker is superseded the moment the tip moves, which in a landing burst is always before the tree publishes. So the base had no "cmux-next daemon tests" verdict for hours, and base_red_excuse.py could not compare any pull request's daemon red with it (#27692, #27868). - cmux-next.yml takes tip_daemon_suite (main's tip suite dispatcher asks for it): path routing routes only the daemon tier, and the run is named `cmux-next tip daemon suite · <tested sha>` (same_tree_sha in same-tree mode). - Its tree wait marker carries tip_suite=daemon. cmux_next_tree_notify.py starts it on the recorded sha after the tip moves (like the DEV daily) and passes tip_daemon_suite on, so the same-tree run keeps the name. Only a daemon-only dispatch on feat-cmux-next heads may carry it. - base_red_excuse.py: when its window of the newest 100 base runs holds no verdict for swift test or daemon tests, it reads the base's newest tip suite runs of that job by name (at most 6 job lists). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(guards): run test_cmux_tui_owned_mini_caches.py, which its registry lane names #27840 registered tests/test_cmux_tui_owned_mini_caches.py as lane "linux-guard" but no ci-guards.yml step ran it, so the execution registry validator fails every pull request into feat-cmux-next ("linux-guard lane is not run by any workflow"). The release-notary group of ci-guards now runs it, beside the other cmux-tui artifact guards. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit 43312b4) * fix(ci): the tree wait marker step reads TIP_DAEMON_SUITE with a default test_a_dispatch_whose_tree_was_building_gets_its_daemon_tests_later runs the marker step's script with its own env, which has no TIP_DAEMON_SUITE, and the KeyError failed "Checks job structure" on #28283. The script reads it with .get(), and the test now covers the tip daemon suite marker: tip_suite=daemon only for a tip_daemon_suite dispatch on feat-cmux-next. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(guards): drop the owned-mini-caches step from this PR Review: this branch's base predates #27840, so tests/test_cmux_tui_owned_mini_caches.py is not in the branch and the step only passed on the merge commit with the base. The registry error it fixed is a base red (feat-cmux-next fails the same way); its fix goes in its own PR from a branch that has the file. This reverts commit c0c10bc. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * fix(ci): the base dispatch fallback takes the newest verdict, green included Review of #28283: the fallback read only tip suite runs, so a newer ordinary dispatch that ran daemon-test (or swift-test) green was skipped and an older red tip suite run excused the head. It now reads the base's completed dispatches newest first and the first with a verdict for the job decides, a green one included. DEV daily runs and the other job's tip suite never run the job and are skipped unread; at most 6 job lists. Test: a newer green ordinary dispatch over an older red tip suite refuses. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts: # webviews/src/agent-session/acpmux/ModelPicker.gallery.tsx
|
Sweep fix: merge conflict with |
|
For awareness: branch |
|
Review (codex gpt-6.1-sol high fast, review-router; started by the backlog lander): SHIP at 4316e93 SHIP No P1, P2, or P3 findings. |
…full model ids (carries #27692) + failed-probe launch tabs (#28050) * fix(picker): give every harness its own rail tab again; pass Claude Code full model ids #26969 folded every harness that draws the Claude or Codex mark into one rail tab. A custom harness such as claude-sr2 (its own profile with icon = "claude") lost its tab and its model list, and Claude Code (acp), Codex (work) and the other launch configurations became launch-only rows. Restore the per-harness rail the picker had before (each harness and launch configuration its own tab with its own models); the later density, search, provider and checkmark fixes stay. acpmux: a chat started or switched with a versioned family name (opus-5-5) failed every turn because Claude Code sent it to the API as typed. The Claude stdio translator now hands Claude Code the full id (claude-opus-5-5) at spawn, on session/set_model and on the model config option. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd * fix(picker): finish the #26969 revert; launch entries list their own models Make the webview side equivalent to `git revert 7f7d931`: the launch-profiles gallery states it added go, and railByHarness keeps its pre-#26969 comment. A launch configuration that is not the running harness (claude-sr2, Claude (work), Codex (work)) was a launch-only tab with no models, before and after #26969. When its own catalog entry lists models, it is now an ordinary rail tab that shows them; picking one starts the chat on that harness, as picking a Codex model does. An entry with no models still launches from its tab. In a started chat every other tab still forks. Format model-menu-started-chat-fork.test.tsx for vp fmt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd * fix(picker): a launch tab lists models only when one can be picked Review follow-ups: a launch entry whose probe failed (every row disabled) keeps its one-click launch tab, the profile branch of railByHarness gets a test (a second launch entry of one family lists its own models and starts itself), and the started-chat rail drops a duplicate return. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd * fix(picker): a launch entry whose probe failed keeps its launch tab Review of #27692 (Codex, BLOCK at a327a7c): `hasModels` checked only the rows' own `disabled`, and the harness-level `HarnessChoice.unavailable` (its probe failed) was dropped when the rail rows were built, so a launch entry whose probe failed but whose catalog still listed models became an ordinary tab that could start a stale model. The QuickFamily now carries `unavailable`, and `hasModels` is false for it, so such an entry launches from its tab, as the PR said it would. A jsdom test covers it. Co-Authored-By: Austin Wang <austinwang115@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd * test(picker): the failed-probe launch entry is the one ComposerPickers keeps in the rail (probeFailed) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd * fix(picker): no stale rows from a failed probe in launch tabs, Starred or search Review of #28050 at 276eb52 (Codex, BLOCK): a launch tab kept its family's rows, so reaching it with the arrow keys (which selects a tab without launching it) showed a failed probe's stale models; Starred and the compact menu's search also listed them. A launch tab now carries no rows, and a harness whose probe failed lends none to Starred or the compact search unless it runs the chat. A jsdom test walks the rail with the arrows. Co-Authored-By: Austin Wang <austinwang115@gmail.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd * Format the started-chat fork test Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Agent-Session: https://cmux.com/deeplink/agent?id=aid-3cf6bed67d0bb92a21bd --------- Co-authored-by: Austin Wang <austinwang115@gmail.com> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
|
Conflict wave: feat-cmux-next already contains this PR's change. 0083a60 "cmux NEXT model picker: every harness its own tab again ... (carries #27692) (#28050)" landed it. Of this PR's added lines, 170 of 189 are present in feat f06d9bd; the rest are later changes on feat to the same code. I pushed no merge. I did not close the PR; a person can close it. |
|
For awareness: this PR has a SHIP review at its head, but GitHub reports it as conflicting with |
|
Awareness note from an agent lane that does not own this PR; it is not a review or a request to take the PR over. Awareness: Batch 6 is building the picker on Lucas’s merged #32980 and preserving its harness/model/effort/account columns. The motion pass applies the shared SlidingIndicator to the family tabs; this lane does not push to #27692. |
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light-3x.png)
Summary
The model picker in cmux NEXT nightly (1.0.0-nightly.4093446036501, built from 6c1a5ab) regressed. This PR fixes two problems.
1. Custom harnesses lost their tab and their models. #26969 (merged 2026-10-29, 7f7d931) folded every harness that draws the Claude or Codex mark into one rail tab (
canonicalHarnesses). A harness likeclaude-sr2, which is its own profile withicon = "claude", disappeared from the rail. It became a launch-only row inside Claude Code's tab and showed no models. Claude Code (acp), Claude Code (sr), Codex (work) and the other launch configurations went the same way.This PR reverts #26969: the webview side is equivalent to
git revert 7f7d9315343c(its two conflicts are context from later commits). It removescanonicalHarnesses, the variants block and thecanonical-harnesses-*gallery states, and restorestest/model-menu-started-chat-fork.test.tsxto its pre-#26969 version. The density (#27320), search grouping (#27303), Provider row (#27151), checkmark (#27232) and empty-search (#26962) fixes stay as they are.The revert alone still left a launch configuration that is not the running harness (claude-sr2 in a Claude Code chat, Claude (work), Codex (work)) as a launch-only tab with no models, as before #26969. Now, when its own catalog entry has a model that can be picked, it is an ordinary tab that lists those models; picking one starts the chat on that harness, as picking a Codex model does. An entry with no pickable models (none listed, or its probe failed) still launches from its tab. In a started chat every other tab still forks; a launch configuration with models now shows "Fork to …" on its tab like any harness, instead of forking on the tab click.
2. GUI chats failed with "There's an issue with the selected model (opus-5-5)". A chat started with a versioned family name (
opus-5-5) failed every turn, while the header still read "Claude Code · Opus 5.5". Claude Code acceptsopusorclaude-opus-5-5, but it sendsopus-5-5to the API exactly as typed. The session's own log shows[claude-code:unrecognized_model] {"model":"opus-5-5"}followed by a 404model_not_found. The Claude stdio translator (claude_stdio::model_id) now passes Claude Code the full id at spawn (--model), onsession/set_modeland on themodelconfig option. It does this only foropus-/sonnet-/haiku-followed by a digit. Aliases, full ids and other providers' names pass through unchanged. This applies the rulelive_models::claude::launch_idalready uses.Testing
Remote runs only (rbx; this Mac had no
agent-identityforcmux-ciand no Freestyle key):picker-restore-27692-web, tree of c329f8d):bun test test/model-menu-started-chat-fork.test.tsx test/model-menu-compact.test.tsx test/model-menu-providers.test.tsx test/signed-out-rail.test.tsx test/composer-footer-harness.test.ts: 82 pass, 1 skip (browser lane), 0 fail. New tests: claude-sr2 keeps its tab and lists its models, mounted onclaude-sr2and onclaude(picking its model startsclaude-sr2); a named entry with models starts from one of them; one with no models still launches from its tab; a second launch entry of one family lists its own models and starts itself.picker-restore-27692, 51f9ccc):cargo test --locked -p acpmux --lib claude_stdio::tests: 19/19, includingversioned_family_names_reach_claude_code_as_full_ids. Later commits touch only webviews.vp fmt --checkover webviews: clean.Changelog
opus-5-5no longer fails every turn with "There's an issue with the selected model".🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmith-botwith what you need.Summary by cubic
Fixes two model-picker regressions in the cmux NEXT nightly: every harness is back to its own rail tab, and versioned model names no longer fail every chat turn.
claude-sr2,Claude (work),Codex (work)) whose catalog entry lists pickable models shows them on its tab, and picking one starts the chat on that harness; one with no models, or whose probe left every model disabled, still launches directly from its tab. Removes thecanonicalHarnessesfolding and the variants submenu; the density, search, provider, checkmark, and empty-search fixes from later PRs stay intact.claude-opus-5-5) at spawn, onsession/set_model, and on the model config option. Bare aliases (opus), full ids, and other providers' names pass through unchanged.Written for commit a327a7c. Summary will update on new commits.