fix(cli): channels get exits non-zero on unknown channel instead of printing null

[obbax]

Summary

buzz channels get --channel <id> for a channel that doesn't exist prints the literal string null to stdout and exits 0 — indistinguishable from success for any script or agent automation that checks exit codes. We hit this in agent tooling where a typo'd channel UUID sailed through a pipeline as "success".

Minimal fix in cmd_get_channel: empty relay response now returns CliError::NotFound("channel '<id>' not found") — the same not-found convention the CLI already uses elsewhere (mem get, projects get, team lookup in this same file) — so it prints an error to stderr and exits 1.

Related issue

N/A — none found (searched issues/PRs for channels get null/exit-code).

Testing

• cargo test -p buzz-cli: 343 passed, 0 failed (Linux x86_64, rust:1-bookworm).
• No new unit test: cmd_get_channel calls the live client directly and the file has no mock-relay infrastructure for async command paths; happy to add one if you'd prefer wiremock-style coverage.
• Manual before/after semantics: before — stdout null, exit 0; after — stderr error: channel '00000000-0000-0000-0000-000000000000' not found, exit 1.

Signed-off-by: obbax robinniclasandersson@gmail.com

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0f86ec53fb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Reject malformed query bodies before reporting absence

When /query returns a successful HTTP response whose body is not a JSON array—for example, a malformed or truncated relay response—line 232 converts the parse failure into an empty vector, so this new branch reports not_found with exit code 1 even though the channel's existence was never established. Propagate the deserialization failure as an unexpected error before testing whether the decoded array is empty.

AGENTS.md reference: AGENTS.md:L195-L197

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Update the channels-get runbook expectations

This changes the documented error-path behavior, but crates/buzz-cli/TESTING.md lines 522–525 still assert that the same unknown UUID prints null and exits 0, while line 136 still says channels get may return null. Anyone following the repository's live-testing runbook will therefore treat the intended new behavior as a failure; update those expectations to the not_found stderr payload and exit code 1.

AGENTS.md reference: AGENTS.md:L202-L202

Useful? React with 👍 / 👎.

[Chessing234]

two siblings share this exact shape, so it's worth being explicit about scope: cmd_get_canvas 25 lines down (channels.rs:277) and the workflow get (workflows.rs:55) both do the same unwrap_or_default -> println!("null") -> Ok(()).

canvas is the one that can't just follow: nest_skill.md:62 documents canvas get as "raw markdown string or null — NOT a JSON envelope", so that's a contract agents are told to expect. changing it means editing the skill and bumping NEST_SKILL_VERSION in nest.rs so installed nests actually refresh — a bigger move than this. channels get has no such documented null, which is what makes it safe to change on its own; worth saying that in the body so the narrow scope doesn't read as arbitrary.

(codex already has the TESTING.md drift and the unwrap_or_default parse masking, so not repeating those.)