[BUG] [PRIVACY] GMail MCP Rewrites URL with google tracking URLS as of 5th of June

The rewritten form you're seeing — https://www.google.com/url?q=…&source=gmail&ust=…&sa=E — is Gmail's own link redirector, not something Claude Code or the MCP generates. The source=gmail / ust / sa=E parameters are Gmail's server-side signature; that wrapper is applied by Google's mail infrastructure to links inside email bodies, which lines up with the external label here.
That said, "it worked in a previous version" is a real signal, so the useful question is what changed on the MCP side that now makes Gmail wrap the links. The usual trigger is the MIME content type of the body:

• If the draft body is submitted as text/plain, Gmail generally leaves URLs verbatim.
• If it's submitted as text/html (or multipart with an HTML part), Gmail tends to rewrap <a href>/auto-linked URLs through the google.com/url?q=… redirector.

So a likely explanation is that the MCP started sending drafts as HTML where it previously sent plain text.
How to pin down where the rewrite happens (and who owns the fix), without guessing:

1. Create the draft as you did, then fetch it back raw via the Gmail API: users.drafts.get with format=RAW (or users.messages.get?format=raw), and base64url-decode the payload.
2. Inspect the raw MIME:

• If the stored body already contains the google.com/url?q=… form → Gmail rewrote it at accept-time (or the MCP sent it pre-wrapped). Check the Content-Type header in that same MIME — if it's text/html, that's almost certainly the cause.
• If the stored body contains your verbatim URL and only the Gmail web UI shows the wrapped form → it's display-layer link-wrapping and the actual stored data is intact.

If the raw MIME is text/html and contains the wrapped URLs, the fix belongs in the Gmail MCP server (send text/plain, or expose a content-type option), not in Claude Code core — and it'd be worth filing against that MCP server repo with the raw MIME attached. If the stored body is verbatim, then nothing was actually modified in your data and it's purely Gmail's render-time redirect.
Either way, the raw-draft dump is the one artifact that settles it conclusively.

Just to verify if google is doing something global I tested with Grok to send an email with https link and there was no URL google.com wrapping then.

Reproducing this via Claude Desktop + Gmail MCP (Gmail:create_draft)

Same issue here. When Claude creates a draft using htmlBody with clean <a href="https://example.com">anchor text</a> tags, the links in the resulting draft already contain the google.com/url?q=... wrapper before the email is ever sent. This means recipients are hitting a redirect warning interstitial and have to click "Continue to site" before the link loads.

The rewriting is happening inside the MCP at draft-creation time, not as a Gmail send-time behaviour. The href in the draft's HTML source is already wrapped when you inspect the draft in Gmail.

Reddit thread also tracking this: https://www.reddit.com/r/ClaudeCowork/comments/1uci5fz/links_in_coworkdrafted_gmail_started_arriving_as/

Still reproducing on v2.1.197 (macOS), ~6 weeks after this report — not fixed.

**Minimal repro (confirms it's not reply-specific): a brand-new draft via create_draft with two plain-text URLs comes back with both** rewritten to https://www.google.com/url?q=…&source=gmail&ust=<ts>&sa=E in the stored body — as visible text, not just the href. Both share one ust= timestamp → a single wrapping pass at creation. No replyToMessageId, no quoted original involved.

Contrast on the same account: creating the identical draft via the community workspace-mcp draft_gmail_message tool stores the URLs verbatim. So the raw URL reaches the pipeline intact — the built-in connector is what mangles it.

Impact: hits client-facing links — e.g. a payment link renders as google.com/url?q=… next to "Pay $X," which reads as phishing on a payment email and forces manual fixes or switching tools.

+1 that URLs should be passed verbatim.