`--reply-to-message-id` silently fails to set In-Reply-To and References headers (drafts and sends)

[mariovallereyes]

Summary

gmail drafts create --reply-to-message-id <id> (and gmail send --reply-to-message-id <id>) sets Gmail's internal threadId correctly, but does NOT add In-Reply-To or References headers to the resulting message. The --help text states it should set both.

External recipients on non-Gmail clients thread by RFC 5322 headers, not by Gmail's internal thread IDs. The result is that what looks like a properly threaded reply inside Gmail arrives in the recipient's inbox as a brand new "Re: ..." email with no thread ancestry.

I caught this in production after sending a reply to an investor. The reply was rendered identical to a faked "Re:" send. From the recipient's perspective there was no threading.

Reproduction

Tested on macOS gog v0.13.0 and Windows gog v0.13.0 (also reproduces on v0.9.0). Replace <MSG_ID> with any real message id from the account.

# 1. Create a draft reply with the threading flag
gog --account you@example.com gmail drafts create \
  --to "test@nowhere.invalid" \
  --subject "Re: Original Subject" \
  --body "test body" \
  --reply-to-message-id <MSG_ID> \
  --json

# 2. Inspect the resulting draft's headers
gog --account you@example.com gmail get <draft-message-id> \
  --format metadata --json

Actual output (headers payload from step 2)

"payload": {
  "headers": [
    { "name": "From",    "value": "you@example.com" },
    { "name": "To",      "value": "test@nowhere.invalid" },
    { "name": "Subject", "value": "Re: Original Subject" },
    { "name": "Date",    "value": "Tue, 21 Apr 2026 00:29:48 +0000" }
  ],
  "mimeType": "text/plain"
}

The returned threadId correctly matches the original. Gmail UI threads it. The headers that any non-Gmail client (Outlook, Apple Mail, mobile clients) actually use for threading are not present.

Expected

Headers payload should include:

"In-Reply-To": "<original-message-id-header-value>"
"References":  "<original-message-id-header-value>"

These are populated from the Message-ID header of the original message (fetchable via the existing gog gmail get <id> call internally). The flag's --help text already promises this behavior.

Impact

• Silent failure mode. The CLI returns success, the response includes a matching threadId, Gmail's web UI shows correct threading. The only way to detect the bug is to fetch the sent message back and inspect its headers, or to ask the recipient.
• Breaks any agent / automation flow that relies on the flag for true threaded replies.
• Distinct from Draft reply via --reply-to-message-id doesn't auto-populate Subject from original message #488 (Subject auto-population) and [Bug] gmail send --reply-to sets wrong timezone (+0900) in Date header causing delivery failure #472 (Date header timezone). Those issues also touch --reply-to-message-id but the missing RFC threading headers are not covered.

Suggested fix area

Wherever --reply-to-message-id is consumed for draft/send construction, fetch the original's Message-ID header and emit:

• In-Reply-To: <Message-ID>
• References: <existing References from original (if any)> <Message-ID>

Happy to test a patch against my repro if useful.

Versions

• gog v0.13.0 (5cd913e 2026-04-20T22:14:47Z) on Windows 11
• gog v0.13.0 on macOS (Apple Silicon)
• Reproduces on v0.9.0 as well

[steipete]

Fixed on main in 63cfefe. Default gmail get --format metadata now includes reply threading headers, and explicit reply targets without a Message-ID now error instead of silently producing unthreaded replies. Verified locally with make fmt, make lint, and make test.