serve summary prints a stop command that fails without --yes

Current behavior

After rocm serve <model> succeeds, the deployment summary prints a stop row that is presented as a ready-to-run command:

service   vllm-qwen-1720000000
stop      rocm services stop vllm-qwen-1720000000
logs      rocm logs --service vllm-qwen-1720000000

Running that exact command fails. rocm services stop refuses to act unless --yes is passed, so the first thing a user does with the hint — copy it and paste it — exits non-zero with a requires --yes error.

The hint is built in apps/rocm/src/serve_summary.rs:134-139, where render_summary emits the service, stop, and logs rows. The logs row is complete, but the stop row omits --yes:

("service", summary.service_id.clone()),
("stop", format!("rocm services stop {}", summary.service_id)),
(
    "logs",
    format!("rocm logs --service {}", summary.service_id),
),

The gate it collides with is in apps/rocm/src/main.rs:6889-6902. run_approved_service_action bails whenever yes is false:

fn run_approved_service_action(
    paths: &AppPaths,
    tool: &str,
    service_id: &str,
    yes: bool,
) -> Result<()> {
    validate_service_id(service_id)?;
    if !yes {
        bail!(
            "{} local server `{service_id}` requires --yes.\n\nTry: rocm services {} {service_id} --yes",
            service_action_verb(tool),
            service_action_command(tool)
        );
    }

So the summary and the command implementation disagree about what the canonical stop invocation is. The error text is helpful — it tells you to add --yes — but the user only sees it after the printed command has already failed.

Expected behavior

The command printed in the deployment summary should be copy-pasteable and succeed as printed. The stop row should read:

stop      rocm services stop <service-id> --yes

A hint that cannot be run verbatim is worse than no hint, because it teaches the user a command form the CLI then rejects.

Steps to reproduce

1. On an interactive terminal, run rocm serve qwen and wait for it to come up.
2. From the deployment summary, copy the stop line exactly as printed.
3. Run it verbatim.
4. Observe the requires --yes error and a non-zero exit status. The service is still running.

Possible solution

Two options, and they point in opposite directions, so this is really a question about which form is canonical:

• (a) Append --yes to the stop row in render_summary, so the printed hint matches what the command actually accepts.
• (b) Leave the hint as the canonical short form and have rocm services stop prompt interactively when it is attached to a TTY, instead of bailing outright.

Option (a) is the smaller change and keeps the existing non-interactive safety gate intact — nothing about the approval semantics changes, only the string that gets printed. Option (b) is a larger behavioral change to the command itself and would need care around the non-interactive path.

Worth noting that the same question applies to rocm services restart, which shares run_approved_service_action and therefore the same --yes requirement. Whichever way this is resolved, both subcommands should end up consistent.

Your environment

• rocm-cli channel: n/a
• rocm-cli version (rocm --version): n/a
• Platform: n/a
• OS / Distro: n/a
• GPU/APU: n/a

This was found by reading the source of main at commit 8557e680 (2026-09-17), not by executing a build, so the environment fields above are genuinely not applicable rather than omitted. The line numbers cited are as they appear at that commit.

Relevant log output

The bail! that rejects the printed command, apps/rocm/src/main.rs:6897-6901:

bail!(
    "{} local server `{service_id}` requires --yes.\n\nTry: rocm services {} {service_id} --yes",
    service_action_verb(tool),
    service_action_command(tool)
);

The stop row that produces the command, apps/rocm/src/serve_summary.rs:135:

("stop", format!("rocm services stop {}", summary.service_id)),

Additional context

Surfaced while fact-checking a hands-on blog post against main — the post reproduced the stop command straight out of the deployment summary, which is exactly the failure path a reader would hit.

Worth adding that the canonical form is already specified in-tree. The test service_actions_require_yes_and_render_sandbox_result at apps/rocm/src/main.rs:25601-25608 asserts that the stop error contains both "requires --yes" and "rocm services stop svc-qwen --yes":

let error = run_approved_service_action(&paths, "stop_server", "svc-qwen", false)
    .unwrap_err()
    .to_string();
assert!(error.contains("requires --yes"));
assert!(error.contains("rocm services stop svc-qwen --yes"));

So the repository already treats rocm services stop <id> --yes as the correct invocation and has a test pinning it. The summary row at serve_summary.rs:135 is simply out of sync with that, which makes option (a) the obviously correct fix — it aligns the printed hint with a form the tree already asserts.

Start in apps/rocm/src/serve_summary.rs at render_summary, then compare the stop row with run_approved_service_action in apps/rocm/src/main.rs. Check the existing service_actions_require_yes_and_render_sandbox_result test for the canonical command form. Done means the deployment summary prints a stop command that includes --yes and matches the repository's asserted invocation.