[teamleaderleo]

Leo #89 item 3, "Chief backends: choose the engine": people pick the engine the Chief runs on (Claude Code through sr2, Codex, OpenCode, the other acpmux harnesses, UniiChat), each engine says what it supports, and a switch applies from the next turn. chief.engine.set {harness} already does the switch: it saves engine.json and the next turn reads it. What was missing is a picker list that comes from acpmux. Today the app's list is the static ChiefBackend.official (claude, codex, unii).

Summary

• chief.engine.get (and the answer to chief.engine.set) now carries offered.harnesses[]. The brain reads acpmux's _acpmux/harnesses on each answer, so a harness installed or signed in since is listed at once. New file Native/OptChat/optchat-chief/src/brain/harness_offer.rs; engine_control.rs adds the field.
• Each row:

  {"id": "opencode", "displayName": "OpenCode", "family": "opencode", "chiefFamily": "other", "kind": "acp",
   "capabilities": {"efforts": ["low", "high"], "speeds": ["default"], "resume": true, "permissionModes": true},
   "unavailable": true, "unavailableReason": "acpmux's opencode is unavailable: opencode is not on PATH",
   "description": "...", "icon": "opencode", "login": "opencode auth login"}

  • family is acpmux's family (opencode, unii, ...). chiefFamily is the layout the Chief gives the harness (claude, codex or other), and the speeds follow it.
  • capabilities.efforts is the profile's declared list, else every effort a set accepts. speeds uses the same check a set runs (fast only on codex). The profile's own resume, permissionModes and fast pass through.
  • The unavailable reason is acpmux's own (a missing launcher) or the harness gate's refusal (a Claude ACP adapter that is not acpmux's claude-stdio), so the picker never offers a harness whose turn would be refused.
  • displayName is the profile's name, else the curated catalog's, else the id. When two profiles share one name (claude and claude-sr are both "Claude Code"), each name gets its id in parentheses.
  • Terminal-only harnesses are left out, since they never run a Chief turn. Rows are ordered by id.
• On the Mac, ChiefEngineHarnessOffer (new file Packages/macOS/CmuxNext/Sources/CmuxNextDaemon/Chief/ChiefEngineHarnessOffer.swift) decodes offered.harnesses from the whole answer. A brain that sends no list gives an empty one, a row the app cannot read is skipped, and pickerOrder puts the available engines first.

Scope

This draft covers the wire and the decode model only. No UI changes, and none of the files #23883 touches (ChiefBackend.swift, ChiefNames.swift, ChiefControlClient.swift, HomeChiefModelMenu.swift, HomeChiefSettingsView*).

Remaining steps:

1. Picker UI, after cmux NEXT: Chief Settings as grouped glass cards, names not ids, a styled last turn #23883 lands: add harnesses to ChiefEngineReport.Offered (or decode ChiefEngineHarnessOffer next to it), then build the Chief Settings harness picker and New Chief from pickerOrder instead of ChiefBackend.official, keeping the static list as the fallback for an older brain.
2. Capability badges: show each row's efforts, speeds (Fast), resume and permission modes. An unavailable row is greyed out, shows its unavailableReason, and offers login as the fix.
3. Switch confirmation: picking another engine says it applies from the next turn (the running turn finishes on the old one) and what changes (model and effort reset to the new harness's own). Then show the brain's answer, or its typed refusal.
4. Follow-up: a harness acpmux added after the Chief started is listed as available, but chief.engine.set still refuses it with unknown_harness, because the set checks against the families the brain read at start. Either mark such a row unavailable ("restart the Chief") or let the set admit it live.

Interpretation: I read "UniiChat-style tree memory" as acpmux's existing unii harness (UniiChat through uniichat-agent). The Chief's own memory is already a tree, so no new memory backend is added here. unii is offered like any other harness (family unii, chief family other), and the compactor stays on Claude.

Testing

• Rust: Native/OptChat/optchat-chief/tests/engine_offer.rs the_engine_answer_offers_every_harness_with_what_it_supports, against a fake acpmux with claude-sr, claude, a refused claude-acp, codex, an unavailable opencode, unii and a terminal aider. Fleet step cmux-tui-rust-check.sh optchat-chief, with no filter:
  • red on the tests-only commit 772ef5f: step 442c49dd01bb57ff09a8b1a5
  • green on 50730eb: step 1fbe3f902a6f672d11e91687
• Swift: Tests/CmuxNextDaemonTests/ChiefEngineHarnessOfferTests.swift. Fleet step package-test-lane.sh suite Packages/macOS/CmuxNext ChiefEngineHarnessOfferTests:
  • Not run yet. Both steps (red 4bb7790656f77d2be81086c7 on b0a3ef3, green c225bda2bb765fc4246af2cc on the head) failed before any test ran, on the base web-bundle red from cmux NEXT Inspector: Context opens to Claude's breakdown; Connectors says N to reconnect #23789 (ContextSection.css missing from build-agent-pane-web.sh; fixes in ci: the agent pane page ships the Inspector's ContextSection.css (base red since #23789) #23935 and cmux NEXT: fleet app builds pass the web step again (agent pane bundles ContextSection.css) #23939). Rerun after one of those fixes lands.
• scripts/cmux-next/prepush-gate.py found no new violations.

Observed / Not run

• Observed: the fleet steps above.
• Not run: the Swift suite (blocked by the base red above), a live brain against a real acpmux, and any app build. There is no UI in this draft.

Proof

No capture: draft, no UI yet

Changelog

none

🤖 Generated with Claude Code
Agent session: cmux16

[teamleaderleo]

Owned by chief-fix-4 on huge-blue · session

[github-actions]

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

Review 3c54c4a: 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=pr23945 -f ref=chief-engine-picker -f platform=macos -f backend_mode=local

red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on 87770f7 to compare; do not merge until green; see lane-rules

[blacksmith-sh]

Found 5 test failures on Blacksmith runners:

Failures

Test	View Logs
nightly.yml prepare-nightly-variant: 'Package prepared app for signing' is not in list/ nightly.yml prepare-nightly-variant: 'Package prepared app for signing' is not in list	View Logs
test_secret_free_prepare_fallback_does_not_requeue_a_retry_on_the_side_pool (main.N ightlyOffBlacksmithTests.test_secret_free_prepare_fallback_does_not_requeue_a_retry_on_ the_side_pool)/ test_secret_free_prepare_fallback_does_not_requeue_a_retry_on_the_side_pool (main.N ightlyOffBlacksmithTests.test_secret_free_prepare_fallback_does_not_requeue_a_retry_on_ the_side_pool)	View Logs
test_the_nightly_is_covered (main.NightlyStepCoverageTests.test_the_nightly_is_cove red)/ test_the_nightly_is_covered (main.NightlyStepCoverageTests.test_the_nightly_is_cove red)	View Logs
test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)/ test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)	View Logs
the architecture gate covers the helper's executable/ the architecture gate covers the helper's executable	View Logs

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

[teamleaderleo]

Bead cx-o8dhi created for this PR by the cmux coordinator.

[teamleaderleo]

cmux-next guards / nightly-guards / workflow-guard-tests / release-notary is red on 15 of 18 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[teamleaderleo]

cmux-next / cmux-next checks (god files, concurrency, crash safety, l10n) › Script tests (pin-cmux-tui, embed-cef, ensure-cef store) is red on 12 of 15 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[teamleaderleo]

cmux-next fast gates / post cmux-next/fast-gates is red on 12 of 17 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[teamleaderleo]

high-signal review link / link is red on 12 of 13 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[teamleaderleo]

Review (codex gpt-6-astra xhigh): SHIP at d7ea6df

• harness_offer.rs:133: Correct predicate: identical trimming and case-sensitive comparison. Default/DEFAULT remain names; default, default , and whitespace-only IDs become unavailable. No introduced panic, borrow issue, or interaction with display-name disambiguation.
• harness_offer.rs:169: Non-blocking diagnostic limitation: “restart” can hide the permanent rename requirement. Availability remains correctly false, but restarting alone cannot make default selectable.
• harness_offer.rs:197,213: Efforts exclude default; speeds legitimately include it as the accepted reset operation. The guard affects harness IDs only. Compactor/classifier harnesses share that sentinel rule; this row does not enumerate model choices.
• engine_offer.rs:521: The availability assertion fails without the fix because the fixture is admitted and present in startup families. The subsequent no-error/unchanged assertion documents the preserved clearing contract, rather than requiring selection of the unreachable profile.
• harness_offer.rs:131: Non-blocking documentation correction: clearing an existing override can restore a different startup harness; it does not universally keep the running harness unchanged.
• harness_offer.rs:227: Verification gap: the supplied packet proves availability metadata, not picker selection enforcement. No picker handler is supplied, so disabled selection remains unverified; this delta itself adds no setter rejection.

Reviewer: Codex gpt-6-astra at xhigh on cmux16 (codex exec --sandbox read-only), a
different model from the author. It was given the fix commit's diff, the full current
harness_offer.rs, the set path of engine_control.rs and the test fixture, and was
told to judge the fix for the one FIX FIRST finding of the previous round
(89a8af8: a profile acpmux calls default was offered as a choice a set reads as
"clear the choice").

Evidence it was given: on the fleet at this commit,
scripts/ci/cmux-tui-rust-check.sh optchat-chief ran the whole crate.
tests/engine_offer.rs: 9 passed, 0 failed. The one crate-wide failure was
acpmux_peer_moved::moved_peer_the_kernel_signature_of_a_peer_whose_executable_is_gone_is_read_and_checked
("its CMS signature does not verify"), a signing-fixture failure that has nothing to do
with this change.

The two non-blocking points I am not acting on here: the "restart the Chief" wording can
read as if a restart would make a default-named profile selectable (it names the rename
in the same sentence), and the picker's own refusal of an unavailable row is not in this
PR — the Swift side has isAvailable/pickerOrder and no picker view consumes it yet, so
there is nothing here to enforce it in. Both belong with the picker UI.

[teamleaderleo]

cmux-next / cmux-next checks (god files, concurrency, crash safety, l10n) › Package dependency lists sorted is red on 6 of 9 fresh feat-cmux-next PR heads in the last 2:00:00, so it is most likely a base red, not this PR's. The base-reds lane has it; a base merge picks up the fix once it lands.

[teamleaderleo]

Review carry: SHIP at dbbbd46

The receipt above (Review (codex gpt-6-astra xhigh): SHIP at d7ea6dfb8911dcace9137efe92b60bd20fd361b3) carries to this head. dbbbd46f23 is d7ea6dfb89 plus one clean merge of origin/feat-cmux-next — no conflicts, no hand-written merge content — and the PR's own patch is byte-identical at the two heads:

git diff origin/feat-cmux-next...dbbbd46f23   # 6 files
git diff $(git merge-base d7ea6dfb89 origin/feat-cmux-next)...d7ea6dfb89
# the two diffs are identical, byte for byte

The merge was taken to pick up #25180 (the web/data/next-docs generated-files baseline) and #25272 (the release-notary highlight fixtures).

Own tests at this head, on the fleet

• ChiefEngineHarnessOfferTests (the Swift side of this PR): passed, 10s — cmux-ci step 68ca28a8bb9d96ed63f71605 on aws-m4pro-3, scripts/ci/package-test-lane.sh suite Packages/macOS/CmuxNext ChiefEngineHarnessOfferTests at dbbbd46f23.
• cargo test --locked --manifest-path Native/OptChat/optchat-chief/Cargo.toml --test engine_offer (the Rust side): 9 passed, 0 failed on the 32-vCPU Linux fast-check lane at dbbbd46f23.

The remaining reds are base reds, none of them this PR's

• rust workspaces / Native/OptChat/optchat-chief — memory_sync_state::tests::a_running_host_is_refused_without_stop_host panicked on the HostLock::take().unwrap(). It is in a file this PR does not touch, rust workspaces is green on the base tip (714af0ca098a, run 40271692320), and the same test passes at this head on the Linux lane (1 passed; 0 failed). A flake in a test that probes a real lock's pid and mtime; it cleared on the rerun here too.
• cmux-next checks — scripts/cmux-next/tests/release-compile-derived-data.test.sh (1 of 112), red at the base tip.
• cmux-next fast gates, high-signal review link, Familiar intent review warning — base reds; base-red-watch posted its findings for the first two on this PR above.
• cmux-next daemon tests, cmux-next generated files — both failed in Set up runner, before any of this PR's code ran: runner infrastructure. The daemon suite's own content is covered by the fleet run above; cmux-next generated files is the ActionContractTests base red that #25220 fixes (cmux open-remote's one-word CLI verb), red on every PR that runs the job.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4030749448501 (b781e3b4a0)
• cmux NEXT nightly 1.0.0-nightly.4031371403702 (1dc93b2657)