hey reply: override recipients (--to/--cc) without losing the thread

[heredia21]

Context

Agents often need to reply in-thread to an address that is not what HEY would pick from the last message — especially with alias / reverse-alias forwards (plus-addressing), ticket systems, and “noreply” envelopes where the human address lives elsewhere.

hey compose --thread-id can approximate this but is easy to get wrong and still isn’t a first-class reply path. After v1.6.0, agents can see the right address (received_via, recipients in hey thread read --json) but still can’t target it on hey reply.

Related: #446 (broader agent ask; this issue splits out the highest-priority remaining item), #431 (envelope visibility — addressed in 1.6.0 via received_via).

No account-specific details below — capability only.

---

Ask

Add recipient overrides on reply that keep threading:

hey reply <thread-id> --to person@example.com -m "..."
hey reply <thread-id> --to a@x.com --cc b@y.com -m "..."
hey reply <thread-id> --to person@example.com --replace-recipients -m "..."
hey reply <thread-id> --to person@example.com --dry-run --json

Behavior

1. --to / --cc / --bcc (repeatable or comma-separated — either is fine if documented)
2. --replace-recipients — when set, overrides replace HEY’s resolved reply recipients instead of merging (recommended default for agent use: replace To at least)
3. --dry-run — print resolved From / To / Cc / Bcc / thread id as JSON; do not send
4. Must remain a reply (same topic / References / In-Reply-To), not a new compose

Out of scope

• Connecting SMTP send-as addresses (see Feature request: add/connect SMTP send-as addresses via CLI #454)
• Bulk trash / sweep filters / body hydration (covered or tracked elsewhere)
• Auto-detecting a “suggested reply-to” from body text (nice later; not required here)

---

Why

1.6.0 gave agents the data (received_via). This gives them the action. Together they remove the main footgun in automated alias-forwarded support/seller mail.

---

Environment

• hey 1.6.0
• Primary interface: --json from agents/automation

[robzolkos]

Thanks for reporting this. I validated it through the CLI, SDK, and Haystack reply path.

The requested flags do not exist today: no --to/--cc/--bcc, no --replace-recipients, and no reply dry run. The TUI permits manual recipient editing, but automation cannot do the same.

The good news is that the existing reply endpoint accepts explicit recipient arrays and still creates the entry with the existing reply/topic relationship. Recipient overrides can preserve threading. Merge-versus-replace semantics can be resolved client-side, and a dry run can load HEY's prefill without issuing the POST.

A temporary focused red test currently fails with unknown flag: --to.

[robzolkos]

Fixed in #474.

hey reply now supports repeatable or comma-separated --to, --cc, and --bcc recipient overrides. These keep the reply in the existing thread.

Use --replace-recipients when HEY's inferred recipients must be replaced completely:

hey reply 12345 \
  --to person@example.com \
  --replace-recipients \
  -m "Thanks for the update."

You can inspect the complete envelope without sending:

hey reply 12345 \
  --to person@example.com \
  --replace-recipients \
  --dry-run \
  --json

The preview includes the sender, subject, account, thread, entry, and final To, CC, and BCC lists.

Thanks for the detailed report and examples. They made the required behavior clear.