Add a Sent / outbound listing (search and box cannot list mail you sent)

[heredia21]

Context

There is no first-class way to list outbound mail from the CLI.

• hey box view documents names like imbox / feedbox. paper_trail / papertrail are not accepted as box names (or the trail box lists as empty).
• hey search --in papertrail does not surface a usable sent archive for scripting.
• hey search --from with the address you actually used on hey compose --from often returns nothing (see follow-up issue on --from semantics).

The workable workaround is hey search --to <one recipient> and repeating that for every address. That does not scale, and it is not how “show me what I sent this week” should work.

No account-specific details below.

Ask

Expose outbound mail as a listable surface, any of:

1. hey sent / hey box view sent (or document and implement the real Paper Trail box name + contents that include your sends).
2. hey search --in sent (or --outbound) with the same --date, --subject, --to, --from, --all, --json flags search already has.

JSON rows should include thread id, subject, recipients, sent time, and app url so a script can diff a local send log against HEY.

Why it matters

After a batch of hey compose calls, the only way to reconcile “did these actually leave?” is N recipient searches. A sent list is the missing half of compose.

[heredia21]

Same outbound-scripting set: compose receipt #468, --from search vs compose #470.

[robzolkos]

Thanks for reporting this. I validated it against current hey-cli, Haystack, and hey-sdk.

The Paper Trail part is stale: hey box view paper trail and hey box view trailbox are supported. Paper Trail is for transactional/inbound mail, not a sent archive.

The actual outbound-listing gap is confirmed. Search has useful filters but no sent/outbound scope. HEY already provides GET /topics/sent.json, and hey-sdk exposes it as Topics().GetSent; hey-cli simply does not wire it to a command.

The likely next step is a first-class sent listing using that SDK operation, with pagination and stable JSON. The remaining output-contract question is whether complete To/CC/BCC data requires bounded hydration of each thread's messages.

[heredia21]

Thanks — and good correction on Paper Trail. hey box view paper trail / trailbox being valid, and Paper Trail being inbound/transactional rather than a sent archive, matches what we should have used. The original report mixed that up with the missing outbound list.

Wiring Topics().GetSent to a first-class command (hey sent or hey box view sent) with pagination and stable JSON sounds like the clean path.

On hydration: a first version that lists thread id, subject, sent time, and app url is already useful. Resolved To (and From / send-as if cheap) is the field scripts need most; full To/CC/BCC can wait if it forces per-thread message loads. --ids-only / --json / --count on that command would match the rest of the CLI.