[teamleaderleo]

claude-sr2 (2026-10-26, relaying Leo's NIGHTLY update): "check-for-updates and install-available-update did nothing ("target -"), while palette.attemptUpdate installed within seconds ... Fix the CLI commands so they install, or return a real error, never "target -"."

Before. Both cmux settings check-for-updates and cmux settings install-available-update replied only with ran true / target -. The check fetched the feed and showed its answer on the notice card, but not on the CLI. The install asked the gate to install but never said whether it did, or why not. From the CLI, a run that did nothing looked the same as one that worked.

After. Both actions report a value through ActionRegistry.track(result:), and action.run answers it as result. This only happens when a caller captures the run (the CLI, action.run, MCP). A menu or palette run is unchanged.

• settings check-for-updates first starts the same check as before, then runs the read-only probe. It answers outcome (update_available / up_to_date / requires_newer_macos), plus current_build, newest_build, newest_version and feed. If the feed can't be read, the run fails with update check failed: <reason>.

• settings install-available-update and palette.attemptUpdate follow the flow:

  • When the update starts installing, they answer state: installing and the relaunch follows.
  • Up to date, a failed check, or a check that ended with nothing to install: the run fails with unavailable and the reason (up to date includes the running build).
  • After 20 s with the download still running, they answer the state reached, with pending: true: downloading with progress, ready, or checking. That's under the action run's 30 s settle limit.

  A note or idle phase that was already there when the action returned (an earlier check's) is not taken as the answer.

• All three actions are marked waitsForResult, so action.run with wait (the CLI) gets the 40 s result deadline instead of the 2 s control-plane one.

Not in this PR: claude-sr2's point 2 (the idle install held the update ~9.5 min behind busy agent turns). The relaunch gate belongs to the cx-oy6yl lane's #24851, which makes every relaunch immediate and isn't in Leo's build yet. That's reported separately.

Tests: UpdateActionResultTests:

• a capturing run of each action yields exactly one result;
• the check answers current and newest, and a failing feed is the run's error;
• the install settles only on installing / note / ended-idle after the phase moves;
• a still-running install answers its state with pending.

Risk: low. Only capturing (CLI) runs change: they now wait up to 20 s for an answer instead of returning at once. The install path itself (installAvailableUpdate) is unchanged.

No capture: CLI output only, no UI change.

Agent session: cosmic-gray

🤖 Generated with Claude Code

---

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

[cursor]

Bugbot needs on-demand usage enabled

Bugbot uses usage-based billing for this team and requires on-demand usage to be enabled.

A team admin can enable on-demand usage in the Cursor dashboard.

[teamleaderleo]

Owned by hotswap-opus on cosmic-gray · session

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	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

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

[teamleaderleo]

cmux-next fast gates / post cmux-next/fast-gates is red on 16 of 19 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.

[github-actions]

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

Review e9028f5: 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=pr25245 -f ref=hotswap-opus/update-cli-result -f platform=macos -f backend_mode=local

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

Tour of e9028f56bb (run): no media. The tour job failed before the tour ran (build or setup); the run log has the output.

[teamleaderleo]

cmux-next guards / nightly-guards / workflow-guard-tests / release-notary is red on 13 of 19 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.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4029396825001 (5392ef3326)
• cmux NEXT nightly 1.0.0-nightly.4030749448501 (b781e3b4a0)