[teamleaderleo]

The Chief pet's quick reply (#21738) checks with process-info that an agent, not a bare shell, is in the terminal's foreground, and then pastes the reply and presses Return. If the agent exits between that check and the paste, the shell runs the reply as a command. Now the daemon does the check itself, right before it writes.

send gets an optional expect_foreground string, behind the new capability send-expect-foreground-v1. Just before writing, the daemon reads the surface's foreground process-group leader again (foreground_process_name, the same value process-info reports as foreground_executable). If that leader isn't the named executable, or can't be read, the request fails with foreground changed: ..., classified as known-not-delivered, and nothing is written. expect_foreground only works with surface. Combined with terminal_id, the request fails with bad request, because a terminal that's still being created has no foreground yet.

On the App side, SendInputRequest and DaemonConnection.send gain expectForeground, and DaemonConnection.typeToForegroundProgram does the check and the two guarded writes, so the App target shrinks. typeChiefPetReply calls it and keeps its runningProgram check as the first gate, then passes the foregroundExecutable it saw on both writes, the paste and the Return.

Closes the follow-up coord-2 asked for when it reviewed #21738. Stacked on #21738: the base is feat/chief-pet-setting. Retarget to feat-cmux-next once #21738 merges.

Compatibility

The send command enum doesn't deny unknown fields, so an older daemon ignores expect_foreground and writes as before. The App's own check still protects that case, with the old small race. Swift leaves the field off when it's nil, so unguarded sends are byte-for-byte unchanged (tested). The spec and all seven generated bindings carry the new field (generate.py --write; --check, check-spec-inventory.py and check-resource-api-boundary.py pass).

Socket policy analysis

• Can it run commands or open content on local objects? No new capability. send already writes input to a terminal, and this field can only make it refuse a write it would otherwise make. The remote relay still refuses send before parsing it (commands.md), so no relay path changes.
• Can it change or destroy objects the caller doesn't own? No. It addresses the same surface with the same authority as before.
• Does it read local state the caller shouldn't see? No. The comparison yields only match or mismatch, and the error text doesn't name the executable it found. Callers with send authority can already read it through process-info.
• Phone lane: the generated DaemonLanePolicy+Fields now allows expect_foreground on send. The phone lane already has send and process-info, so this field adds no read, and it can only make the daemon refuse a write.
• No command-bearing params, no new method, and no relay allowlist change.

Verification

• Red first: a17e544 and 3707e5c add cli/send_expect_foreground.rs. Hosted run 39179652753 fails a_reply_for_an_exited_program_never_reaches_the_shell on Linux and macOS with the reply reached the shell: {"data":{},"id":4,"ok":true}.
• Green: hosted run 39203646531 on ad26943 passes all three tests on Linux and macOS, plus clippy and fmt. The Rust SDK (cargo check -p cmux-sdk --all-targets) builds. A re-run on the merge head 8765203 is in progress.
• Swift: new SendInputRequestTests (the encoded wire has expect_foreground, and an unguarded send omits it). No Swift toolchain on the authoring box, so these tests and the App change are compiled and run only by this PR's CI.
• verify-local.py --affected: every selected check passes except localization, which fails with the base branch's existing needs_review catalog entries. This PR changes no strings.
• No live dogfood: reproducing the race in the app depends on exact timing. The hosted tests drive the real daemon: sleep exits via Ctrl-C, then a guarded paste is refused and never reaches the shell.

Changelog

• Fixed: A Chief pet quick reply no longer runs as a shell command when its agent exits just before the reply is typed.

🤖 Generated with Claude Code

---

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

---

Summary by cubic

Closes the race where a Chief pet quick reply was typed as a shell command when its agent exited between the app's foreground check and the paste. The daemon now verifies the foreground itself, right before it writes.

send gains an optional expect_foreground field behind the new send-expect-foreground-v1 capability. Just before writing, the daemon re-reads the surface's foreground process-group leader; if it isn't the named executable, or can't be read, the request fails with foreground changed: ..., writes nothing, and is classified as known-not-delivered. The app names the executable its existing process-info check saw on both the paste and the Return writes, and treats the capability as optional so an unguarded reply is still noted when an older daemon lacks it.

Older daemons ignore the field, leaving unguarded sends byte-for-byte unchanged. The field requires surface; combined with terminal_id the request fails as not delivered. The check is best effort: the program can still exit between the read and the write, a window of microseconds instead of a client round trip.

Tests

• Hosted CLI tests drive a real daemon: a guarded paste is refused and never reaches the shell once sleep exits via Ctrl-C, and the foreground check covers a running program, terminal_id, and an unreadable foreground.
• New Swift tests assert the guarded wire payload and an unguarded send carrying no field; all seven SDK bindings carry expect_foreground.

^{Written for commit 4cfeafc. Summary will update on new commits.}

[greptile-apps]

Confidence Score: 4/5

[Medium impact] The change reaches terminal input in the Chief pet workflow and adds an optional send contract for protocol clients.

The PR should not merge yet because a guarded reply can still reach the shell after the terminal-host connection waits or queues input.

Findings

1.  Replies still reach the shell ▶

Summary

This PR adds an optional foreground check to terminal input.

• A guarded terminal send stops when its named program leaves the foreground.
• Chief pet replies carry the checked program through both writes.

Diagram

sequenceDiagram
  participant App
  participant Daemon
  participant Host as Terminal host
  participant PTY
  App->>Daemon: process-info
  Daemon-->>App: Foreground executable
  App->>Daemon: send with expect_foreground
  Daemon->>Daemon: Compare current foreground
  alt Foreground differs or cannot be read
    Daemon-->>App: Refuse without writing
  else Foreground matches
    Daemon->>Host: Send input bytes
    Host->>PTY: Write input
  end

Loading

_{Reviews (5) · Last reviewed commit: "cmux NEXT: the guarded pet reply lives o..." · Reviewed by Greptile}

[greptile-apps]

Replies still reach the shell

The foreground check runs before the terminal host receives the input. write_paste and write_bytes send bytes over another connection. send_hosted_input can wait up to five seconds for that connection to recover, then retry without checking the foreground again. If the agent exits during that wait, the reply reaches its shell despite expect_foreground.

Even without reconnecting, both quick-reply requests can pass their checks before the host consumes their queued frames, letting the shell run the reply as a command. Carry the expectation to the PTY owner and check it after any wait, immediately before writing.

Knowledge Base Used: TUI client and relays

[teamleaderleo]

Correctness-first review (opus subagent) at f336cfc: SHIP with nits, no blockers. Each nit is fixed at ee8ad50:

1. NotificationCenterService+ChiefPet.swift never checked send-expect-foreground-v1, so against an older daemon the guard silently did nothing. Now the app reads the capability and notes the reply as "(unguarded)" when the daemon lacks it. The reply still goes, checked one round trip early as before, so older Cloud daemons keep working. The capability is in DaemonCapabilities.optional and plans/cmux-next/daemon-capabilities.json; check-app-capability-references.py passes.
2. send_expect_foreground.rs had no case for a foreground that can't be read. New test a_reply_is_refused_when_the_foreground_cannot_be_read: the shell exits, then a guarded send must return ok: false. It's committed before the fixes. It hasn't run locally (no cargo on this Mac, and Huge Blue is unreachable), so this PR's cmux-tui CI is its first run.
3. cmd_terminal_io.rs: expect_foreground with terminal_id used a plain bail!. It's now known_not_delivered, like the other send refusals.
4. spec/commands.md: added that the check is best effort, with a window of microseconds between the read and the write.

[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.

[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.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.3937100371101 (f4c2e82984)