Summary

With hey-cli 1.7.0 (Linux), replying in a thread whose latest entry was sent from a send-as address reports success, but nothing is delivered: the message stays in Drafts and never appears in the thread. Running hey draft send on that draft also reports success and has the same result. Because both commands exit ok, an agent or script assumes the email went out.

Steps to reproduce

1. Pick a thread whose latest entry you sent from a send-as address (not the primary @hey.com identity).
2. Check the envelope:

   hey reply <thread-id> --replace-recipients --to a@example.com --cc b@example.com --dry-run
   

   This resolves correctly: "from": {"email_address": "<send-as address>"}, with the right To and CC.
3. Send it:

   hey reply <thread-id> --replace-recipients --to a@example.com --cc b@example.com -m "..."
   

   Output: {"ok": true, ..., "summary": "Reply sent"}
4. hey thread read <thread-id> --json: the entry count is unchanged, even after several minutes.
5. hey draft list --json: the reply is there as a draft (subject Re: ..., from = the send-as address, correct To/CC and body).
6. hey draft send <draft-id>: {"ok": true, "data": {"id": <draft-id>}, "summary": "Draft sent"}
7. Polling for about 2 more minutes: the thread still has the same number of entries, and the draft is still in hey draft list.

Expected

Either the reply is delivered (it shows up in the thread and leaves Drafts), or the command exits non-zero with the server's reason. A success summary should only be reported once the message has actually left Drafts.

Actual

Both commands report success while the message stays an unsent draft. Sending from the HEY web app is the workaround.

Notes

• Related but different: hey compose --from / draft from: succeeds but send still uses primary HEY identity #483 (send-as used the wrong identity, closed), hey compose can return 502 after the message was sent (outcome unknown) #520 (502 after a send, outcome unknown), hey compose: idempotency key so a rerun does not send twice #477 (idempotency for reruns). Here there's no error at all, just a false success.
• A post-send check would help agents: after reply / draft send, confirm the draft is gone or the thread grew, and report something like "delivered": false otherwise.
• I didn't retry beyond that, to avoid sending a duplicate to the recipient.