Reported issues for gmail-mcp
Pod holds 10 of 10 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to gmail-mcp.
Most discussed
Notes from a production deployment
First, thank you for this project. We needed exactly one thing that Anthropic's built-in Gmail connector doesn't do — return the contents of an attachment — and gmail-mcp was the only self-hostable option we found that treats the Google credential as something the operator keeps. The commit history was a large part of why we chose it: spend a one-time state when it is read, not after it is checked and drop a client-supplied grant header at the boundary are not the commits of someone who
Read the thread · 2026-08-29 · open · external user · 0 comments
Decide when to adopt the 2026-07-28 MCP specification
The 2026-07-28 revision makes the protocol stateless: the initialize handshake and the Mcp-Session-Id header are retired, each request carries its own identity and capabilities in _meta, method and tool names move into Mcp-Method and Mcp-Name headers, and Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents.
The session model is load-bearing here. The Durable Object is addressed as streamable-http:${sessionId}, and the owner claim in its storage, `isOw
Read the thread · 2026-07-29 · open · 0 comments
list_drafts sends metadataHeaders to an endpoint that has no such parameter
list_drafts requests format=metadata with metadataHeaders=To&metadataHeaders=Cc&…. The users.drafts.get method accepts only format, id and userId; Google's frontend ignores unknown query parameters rather than rejecting them, so the call returns every header instead of the four intended.
Nothing fails. Draft header blocks are small, so the cost is a little wasted payload per draft. Removing the parameters is near-zero risk and buys correspondingly little.
Read the thread · 2026-07-29 · open · 0 comments
inlinePart has no Content-ID length guard
filePart measures its assembled header lines and refuses a filename that cannot fit. inlinePart validates the shape of a Content-ID but not its length, so a cid above roughly 985 characters produces a header line past 998 octets.
The value is caller-supplied and nothing plausible writes one that long. Gmail refuses the send either way, so the outcome is an error with a less useful message.
Read the thread · 2026-07-29 · open · 0 comments
create_draft refuses a subject carrying a line break
assertHeaderSafe rejects any header value containing CR or LF, and a test pins that subject: "s\nX-Evil: 1" throws. That is deliberate: refusing an injection attempt in a caller-supplied subject is the safe answer.
It also blocks an ordinary flow. Gmail returns some notification subjects with a trailing newline — Search Console and Google Store both do — so a model that reads a subject with get_message and passes it to create_draft, send_message or update_draft gets a hard error nam
Read the thread · 2026-07-29 · open · 0 comments
reply_all sends threadId without In-Reply-To when a message has no usable Message-ID
reply_all drops the threading headers when the original's Message-ID fails normalizeMessageId, and still sends threadId on the request.
Google documents that adding a message to a thread requires the thread id, References and In-Reply-To set per RFC 2822, and a matching subject. This request meets the first and not the second.
What Gmail actually does with it is unverified: it may accept the message, deliver it as a separate conversation, or refuse the request. Each outcome implies
Read the thread · 2026-07-29 · open · 0 comments
A claimed session cold-woken by another account answers 500, not 403
When a session object is cold and a request arrives carrying a different account's grant, init() refuses through ownerProps() and the exception propagates out of getAgentByName. The caller receives a 500, and the isOwnedBy branch a line below — written to answer 403 for exactly this case — is never reached.
Access is denied either way, the object recovers for its owner on the next request, and reaching the path at all requires the victim's session id.
The warm-object case does return t
Read the thread · 2026-07-29 · open · 0 comments
get_thread's oversize fallback counts a failed fetch as omitted
In the fallback, kept filters out any message whose individual fetch failed, and omitted = all.length - kept.length absorbs the loss. The reply reports a count with fewer messages in it and no indication which are missing or why.
The rest of the server does the opposite: search_messages and list_drafts pass {error} items through in place, and the second map in get_thread itself lets them through on the normal path.
The failure is incompleteness, never wrong content, and it only occ
Read the thread · 2026-07-29 · open · 0 comments
Most recent
get_thread's oversize fallback retains maxMessages × 6 MB
The normal get_thread path bounds a whole thread to one 6 MB response. When that response is refused, the fallback lists message ids and fetches a window individually, each capped at 6 MB, and holds every parsed message before the character budget trims anything at src/index.ts:485.
Measured through the handler: a fallback over 24 messages, each carrying a 1,000,000-character encoded body, fetched and retained all 24 and grew process RSS by 286,212,096 bytes. Cloudflare allows [128 MB per i
Read the thread · 2026-07-29 · open · 0 comments
fitsHeaderLine measures characters against a limit that means octets
MAX_HEADER_RUN (900) exists to keep a header line inside RFC 5322's 998-octet cap, but fitsHeaderLine in src/gmail.ts compares run.length, which counts UTF-16 code units. A run outside ASCII therefore passes a check it should fail.
Two entry points reach it:
- A bare address of roughly 330+ CJK characters.
In-Reply-To/References: a 606-character multibyte message id survivesnormalizeMessageIdand produces a 1,205-octet line.
The outcome is a refusal from Gmail rather th
Read the thread · 2026-07-29 · open · 0 comments
The remaining reports are on the project's issue tracker.