Skip to content

feat(cli): add --content-file to messages send - #5246

Open
jcg-git wants to merge 1 commit into
block:mainfrom
jcg-git:feat/messages-send-content-file
Open

feat(cli): add --content-file to messages send#5246
jcg-git wants to merge 1 commit into
block:mainfrom
jcg-git:feat/messages-send-content-file

Conversation

@jcg-git

@jcg-git jcg-git commented Aug 7, 2026

Copy link
Copy Markdown

Summary

Adds --content-file <path> to buzz messages send, reading the message body directly from a UTF-8 file. Mutually exclusive with --content; the existing --content - stdin form is unchanged.

Why

--content/stdin both require the caller to either quote the body inline or use shell redirection/a pipeline (printf ... | buzz messages send --content -). Some ACP-hosted CLI agents (Codex, in our case) evaluate each shell pipeline segment as a separate command needing its own interactive approval — so a pre-authorized buzz messages send allow-rule doesn't cover the printf | buzz messages send - shape at all, breaking unattended sends for any multi-line/markdown content. --content-file is a single direct command with no redirection or pipeline, so it's covered by a plain command-prefix allow-rule.

This came up concretely running a Codex-backed managed agent (Cocky) that needed to post a saved review file — happy to link more context if useful.

Related

Testing

  • cargo test -p buzz-cli — new focused tests: reads UTF-8 verbatim, rejects a missing file as a usage error, rejects invalid UTF-8, rejects supplying both/neither of --content/--content-file.
  • cargo test --manifest-path desktop/src-tauri/Cargo.toml — Nest/skill-doc tests updated to cover the new example.
  • Full pre-push hook suite (rust-tests, desktop-tauri-checks) passing locally.
  • Manually verified end-to-end: a real managed Codex agent sent a real multi-paragraph review file via --content-file and it posted correctly.

🤖 Generated with AI assistance (Claude Code + Codex), reviewed before submission per this repo's AI-assisted PR policy.

Sending multi-line or code-containing content through --content or
stdin requires shell redirection/pipelines, which some ACP-hosted
CLI agents (e.g. Codex) evaluate as separate command segments needing
their own interactive approval -- breaking unattended sends entirely.
--content-file reads the message body directly from a UTF-8 file,
avoiding redirection/pipelines so a single command covers the whole
send. Mutually exclusive with --content; existing --content - stdin
form is unchanged.

Signed-off-by: Vijay Java <molty@molty.local>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triage-ready Appropriate for agentic review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants