[teamleaderleo]

Bead cx-odyw4. cmux status set run the moment a new tab's shell starts could fail with no terminal matches "term_...", so the status never showed (seen while seeding #20637's captures).

Cause

• A new terminal's shell process starts before the daemon commits its tab. The terminal host holds back only the shell's output until the commit (activate_hosted_launch_stream), not the shell itself.
• Inside a terminal, status set with no workspace finds the caller's workspace from CMUX_TUI_TERMINAL_ID: terminal, tab, pane, screen (cli/resolve.rs). Before the commit the daemon shows no such terminal, so the first lookup failed at once.
• Exit status: on this base the failed lookup already exits 1 (Failure::Resource). I found no path in cmux status set that turns it into 0. The one designed exit 0 is cmux status run, which runs its command even when it cannot mark the status busy and exits with the command's status. The seed's 0 most likely came from how the seed ran the command. The new test pins exit 1.

Fix

• When the caller's terminal is missing, the CLI opens session.events on a second connection to the same socket and looks again after each event. The wait ends when the terminal is in a workspace, or after 3 s.

• The stream starts with a snapshot, so a commit between the first look and the subscription still wakes the wait. Each event is buffered on its own connection, so no wake is lost while a lookup runs.

• A terminal that never joins exits 1 with selector.not_found: "the caller's terminal term_... did not join a workspace of this cmux session within 3s; name one: cmux workspace …".

• No daemon or protocol change; session.events is an existing read. No new CLI case, so the case coverage and relay policy are untouched.

• Only a miss of the caller's own terminal waits. Any other miss, such as an unknown --machine, is reported at once as it is.

Cost: a stale CMUX_TUI_TERMINAL_ID, such as a closed terminal's, now fails after 3 s rather than at once. Only the caller-workspace lookup waits. status set --target ws_... from a brand-new terminal can still be refused with "owner.terminal ... is not a terminal of this session"; that path is not covered here.

Tests

tests/cli/status.rs, through the CLI and a real headless daemon:

• status_set_from_a_terminal_at_its_first_command_reaches_its_workspace: five workspace run terminals each run cmux status set as their first command. Each must exit 0, and its entry must be in the workspace.
• status_set_from_an_unknown_terminal_exits_non_zero_after_a_bounded_wait: a caller terminal the session never shows exits non-zero within 15 s, with selector.not_found and a message naming the terminal and cmux workspace <workspace>.

Receipts

Red, tests on base code (fdf692516ab8, branch op-next-icons/status-set-race-red: the PR's tests, formatted, with no fix; hosted run 38648294325):

• macOS: both tests fail. The race test reproduced the bead's failure: status set in new terminal term_9550… failed: {"code":"selector.not_found",…,"message":"no terminal matches \"term_9550…\""}, exit 1. The unknown-terminal test fails on the message: no cmux workspace <workspace> hint.
• Linux: the unknown-terminal test fails the same way. The race test passed there: the commit won the race on that runner.
• So the race test reproduces on macOS, not on every runner. The unknown-terminal test is the red proof everywhere.
• An earlier red dispatch on the first test commit (7ebc98dfe82f, run 38646000057) never reached the tests: rustfmt failed on that commit, and the macOS lane was refused by a host lock.

Green and Windows on the head (e32be89cd9e3, this branch merged with feat-cmux-next 38c5c3c7f0a9; full hosted run 38655302576):

• test (linux): both new tests ok. The job fails later in smoke-tui.py line 953, a workspace-order assertion. That is a base red: the same assertion fails in another branch's full run (38650424161).
• macOS lint and tests: success.
• Windows: test (windows): success, and release-path dogfood artifacts / build x86_64-pc-windows-gnu: success. Both cover cmux-tui-core and cmux-tui. The earlier full run (38651591314, before the base merge) failed these two on crate::app_identity in cli/wire/socket.rs, which this PR does not touch; base has fixed that since.

Merge state: held. cmux-next checks is red on two base reds this PR does not touch: literal state root in chief_brains.rs and a concurrency violation in IdleOwnerRestart.swift. #20767 fixes both. cmux-next fast tier was cancelled.

Other checks: crash ratchet ok; Opus review found no blocking issues. Its one low finding is fixed in this PR: an unrelated selector.not_found no longer waits.

Changelog

• Fixed: In cmux NEXT, cmux status set run as a new tab's first command now waits for the tab to be ready and sets the status, instead of failing with "no terminal matches".

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: Repository: manaflow-ai/cmux/.coderabbit.yaml
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 5e1e0549-7316-4051-9453-4bf1c0b7cf49

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}