[BUG] Gmail MCP: create_draft produces phantom drafts on threads — likely missing In-Reply-To/References headers

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When Claude uses gmail_create_draft with a threadId to create a reply draft on an existing thread, and the draft is later revised (creating a second or third draft on the same thread), the older drafts become "phantom" entries in the Gmail web UI.

Symptoms:

• The Gmail thread list shows multiple "Draft" labels (e.g., "Draft, Draft, Draft") on the affected thread
• Clicking into the thread only shows the most recent draft
• The older drafts are not visible as editable compose windows inside the thread
• They do not appear as individual items in the Drafts folder
• There is no way to select or delete them in the Gmail web UI
• The Gmail API drafts.list endpoint does return these phantom draft IDs, and drafts.delete can remove them — but most users don't have API access

Likely cause: The Gmail API requires In-Reply-To and References headers when creating a threaded draft reply. Without these, drafts "float" invisibly in the thread history. The MCP tool documentation states these are "automatically set from the last message in the thread," but the phantom behavior suggests they may be missing or malformed.

Additionally, when a user asks Claude to revise a draft, the MCP creates a new drafts.create call instead of updating the existing draft via drafts.update. This produces duplicate drafts on the same thread that accumulate as phantom entries.

What Should Happen?

1. Drafts created with threadId should include valid In-Reply-To and References headers per RFC 822, so they anchor correctly in the Gmail UI
2. When revising an existing draft on the same thread, the MCP should use drafts.update instead of drafts.create to replace the draft in place rather than creating duplicates
3. Alternatively, expose a gmail_delete_draft tool so users can clean up phantom drafts without needing direct API access

Error Messages/Logs

No error is returned. The create_draft call succeeds and returns a valid draft ID. The problem is only visible in the Gmail web UI where phantom "Draft" labels appear on the thread but the drafts themselves are inaccessible.

Steps to Reproduce

1. Ask Claude to draft a reply to an existing Gmail thread
2. Claude calls gmail_create_draft with threadId — draft appears correctly
3. Ask Claude to revise the draft (e.g., "add a paragraph about X")
4. Claude calls gmail_create_draft again with the same threadId — a second draft is created
5. In Gmail web UI, the thread now shows "Draft, Draft" in the thread list
6. Click into the thread — only the newest draft is visible
7. The older draft cannot be found, opened, or deleted anywhere in the Gmail UI
8. Repeat steps 3-4 to produce additional phantom drafts

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

 2.1.85

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Related issue: #45775 reports that the newer MCP tool schema dropped the threadId parameter entirely. This issue describes the behavior when threadId is present but the resulting drafts don't anchor properly in the Gmail UI.

Affected threads: Multiple threads across different contacts over several weeks. Not a one-time occurrence.

Workaround: Phantom drafts can be deleted via the Gmail API drafts.delete endpoint using draft IDs obtained from drafts.list.
This requires OAuth credentials and API access that most users won't have. No workaround exists within the Gmail web UI.