gmail drafts create/update: add --thread-id for parity with gmail send

[chrischall]

Summary

gog gmail send accepts --thread-id ("Reply within a Gmail thread (uses latest message for headers)"), but gog gmail drafts create and gmail drafts update do not — they only accept --reply-to-message-id. There's no thread-aware reply path when composing a draft.

Why it matters

Callers who know the thread they want to reply to (but not the specific latest message id) have nowhere to put it. Passing a thread id into --reply-to-message-id produces a draft that lands in the thread via subject/participant fallback but is not anchored to the parent's RFC822 Message-Id — so In-Reply-To/References are wrong and Gmail doesn't render it as a clean reply. It fails silently (no error), surfacing only when a human opens the draft.

Thread ids and message ids are both 16-hex strings, so this mix-up is easy and undetectable from the value alone.

Proposal

Add --thread-id to GmailDraftsCreateCmd and GmailDraftsUpdateCmd, mirroring gmail send:

• Resolve the latest message in the thread and set In-Reply-To/References from its Message-Id (same helper send already uses).
• --reply-to-message-id and --thread-id are mutually exclusive (match send's use only one of … guard).

Repro

1. gmail thread get a multi-message thread; note the latest message's top-level id vs its headers Message-Id.
2. gmail drafts create … --reply-to-message-id <THREAD_ID>.
3. Observe the draft's In-Reply-To is not the latest message's RFC822 Message-Id.
4. Desired: gmail drafts create … --thread-id <THREAD_ID> anchors to the latest message, exactly like gmail send --thread-id.

(Reported via the gogcli-mcp wrapper; the wrapper will resolve thread→latest-message client-side in the interim, but native --thread-id is the correct home for this.)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 1, 2026, 11:54 PM ET / 03:54 UTC.

Summary
Keep open. Current main still lacks --thread-id on Gmail draft create/update while gmail send supports it; the existing compose helper already has thread-aware reply resolution, so this is a narrow, actionable parity gap.

Reproducibility: yes. at source level: current main defines --thread-id for gmail send but not for either draft command, and the generated docs match that gap. The Gmail UI threading effect was not live-tested in this review.

Next step
This is a narrow, source-confirmed Gmail CLI parity fix with clear implementation files and validation path.

Review details

Best possible solution:

Implement the flag by reusing the existing thread-aware reply helper, add mutual-exclusion validation and tests, update generated command docs, and require redacted live Gmail proof before merging.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: current main defines --thread-id for gmail send but not for either draft command, and the generated docs match that gap. The Gmail UI threading effect was not live-tested in this review.

Is this the best way to solve the issue?

Yes: adding the flag and routing it into the existing prepareComposeReply thread path is the narrowest maintainable fix. It should keep --reply-to-message-id mutually exclusive and avoid changing unrelated draft update fallback behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Live Gmail behavior still needs validation because this review confirmed the gap from source and docs but did not create or update a real draft.
• The fix should preserve existing --reply-to-message-id behavior, the update command's existing-draft thread fallback, and parseable dry-run/JSON output.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 096323d506b9.

Label changes

Label changes:

• add P2: This is a bounded Gmail draft reply correctness and ergonomics gap with limited blast radius.
• add impact:message-loss: Wrong reply headers can cause Gmail replies created from drafts to render or thread incorrectly.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a bounded Gmail draft reply correctness and ergonomics gap with limited blast radius.
• impact:message-loss: Wrong reply headers can cause Gmail replies created from drafts to render or thread incorrectly.

Evidence reviewed

Acceptance criteria:

• go test ./internal/cmd
• make test
• With a redacted live Gmail account, create or update a draft using --thread-id in a multi-message thread and verify the draft has the latest parent message's In-Reply-To and References.

What I checked:

• Send command already has the requested behavior: GmailSendCmd defines ThreadID and rejects using it together with --reply-to-message-id; it also allows quote/reply-all with either reply target. (internal/cmd/gmail_send.go:23, 096323d506b9)
• Draft create lacks the requested flag: GmailDraftsCreateCmd exposes --reply-to-message-id but no --thread-id, and its compose input hardcodes ReplyToThreadID to an empty string. (internal/cmd/gmail_drafts.go:250, 096323d506b9)
• Draft update lacks the requested flag: GmailDraftsUpdateCmd also exposes only --reply-to-message-id; thread fallback exists for preserving an existing draft thread, not for accepting a caller-provided thread ID. (internal/cmd/gmail_drafts.go:508, 096323d506b9)
• Existing helper can implement this narrowly: prepareComposeReply delegates to fetchReplyInfo, which accepts a thread ID and selects the latest thread message for reply metadata. (internal/cmd/gmail_reply.go:70, 096323d506b9)
• Generated command docs confirm the surface gap: The send docs list --thread-id, while the draft create/update docs list only --reply-to-message-id for reply targeting. (docs/commands/gog-gmail-drafts-create.md:43, 096323d506b9)
• Latest release has the same gap: Inspecting v0.21.0 shows GmailDraftsCreateCmd still has no ThreadID field, so the request is not already shipped. (internal/cmd/gmail_drafts.go, 2c84d8981dd5)

Likely related people:

• steipete: Introduced send-side thread ID replies and recently hardened draft reply thread fallback in the same Gmail compose area. (role: adjacent feature owner; confidence: high; commits: 716106da4f22, ce9a89adfeea; files: internal/cmd/gmail_send.go, internal/cmd/gmail_drafts.go, internal/cmd/gmail_reply.go)
• antons: Authored the drafts update command and shared draft compose core that this change would extend. (role: draft command contributor; confidence: medium; commits: 21fbf16390e7, a528467dcd8e, 4e92b5972b7d; files: internal/cmd/gmail_drafts.go, internal/cmd/gmail_drafts_cmd_test.go)
• salmonumbrella: Added draft reply quote support and has recent history around Gmail draft reply behavior. (role: recent draft reply contributor; confidence: medium; commits: 5234214de33f, 4abcd03; files: internal/cmd/gmail_drafts.go, internal/cmd/gmail_drafts_cmd_test.go)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.