Gmail Rewrites Your Emails After You Hit Send

August 2, 2026

I sell a children's board book called 1 2 3 Ski With Me. It's a side business, and most of the operations run through Claude Code: quoting printers in China, talking to the US fulfillment warehouse, submitting orders over an XML API from 2009, and emailing customers through a little Gmail CLI skill.

For about two months, some of those emails arrived looking like this:

Hi Sara,

Please add us to the Auto Disposal list. Shipping hurt stock back to
Australia doesn't stack up cost-wise, and I'm happy for anything
unsaleable to be disposed of straight after processing.

Hard line breaks mid-sentence, wrapped at about 70 characters, like an email from 1998. Not all of them. Just some. To customers and suppliers, from a business trying to look like it has its act together.

I asked Claude to fix it. Five times.

The Five Fixes

Claude Opus took a swing at this on five separate occasions, and every fix was reasonable. It added formatting rules to the skill doc: one line per paragraph, let the mail client wrap. It wrote a Python guard that detects hand-wrapped prose and refuses to send it. When an agent found the guard's bypass flag and used it, we hid the flag from the error message.

After each fix, it verified: open the sent email, check the body. Clean. One long line per paragraph, exactly as intended. Bug fixed.

Then a few days later another customer email would land wrapped at 70 characters.

Debugging It Properly

This week I gave the bug to Fable.

Instead of patching the send code again, it pulled the raw MIME source of my last 160 sent emails and fingerprinted every one. All the emails sent by the skill were stored perfectly, one line per paragraph. Then it went further: it dug the exact commands out of old session transcripts and confirmed the body text passed to Gmail was clean in every single broken case. The skill had never sent a wrapped email.

So where were the line breaks coming from?

The broken emails had a different fingerprint. The charset had changed from us-ascii to UTF-8, and the delivery headers showed a hop through Amazon SES. One of them had been drafted and sent by the skill 7 seconds apart, no human in the loop, submitted clean, delivered wrapped. Something was rewriting the email after we hit send.

Gmail Rewrites Your Email After You Hit Send

Here's the actual bug. My emails go out from will@shredcrew.ski, which is a Gmail send-as alias. For a custom domain, Gmail requires the alias to relay through an external SMTP server, mine goes through Amazon SES. And when Gmail relays a message through that path, it doesn't forward what you submitted. It re-serializes the whole message, and it hard-wraps plain text at about 72 characters on the way through.

The copy in your Sent folder is stored before the relay. It stays clean forever.

Fable proved it with one self-test. Same email, submitted once:

This is a deliberately long single-line paragraph to test whether
the Gmail send-as SMTP relay through Amazon SES re-wraps plain text...
(stored as ONE line, exactly as submitted)

This is a deliberately long single-line paragraph to test whether the
Gmail send-as SMTP relay through Amazon SES re-wraps plain text bodies
at around seventy-two characters even when the submitted raw message
(wrapped at 70 chars, charset rewritten)

So all five fixes were treating a bug that didn't exist, and all five verifications were reading evidence that could never show the real one. The Sent folder is the wrong side of the bug. You have to check what the receiver got.

The fix that works: send every email as multipart/alternative, plain text plus an HTML part. The relay still mangles the plain text, but it passes HTML through untouched, and HTML is what every mail client renders. Verified end to end through the live relay. Fixed in one session.

What This Says About the Models

To be fair to Opus, formatting rules and a validation guard are what I would've tried too. The mistake was the test: we kept checking the Sent copy, and the Sent copy always looks good.

Fable didn't touch the code until it had the raw bytes of what was submitted and what was delivered, cross-referenced against transcripts of what was commanded.

I run a real business on these tools, and this gap matters more to me than any benchmark. A model that fixes the wrong bug confidently five times costs more than one that's slower to act. Good debugging is mostly going and getting the evidence that can prove you wrong, and this is the first model I've used that does that without being told.

So far I don't understand people who find Fable no better than Opus. It's smart, creative, determined, and fast.

Anyway. If your emails are mysteriously wrapping at 72 characters and your Sent folder swears they're fine, now you know. And to the 41 customers who got the ugly version of my shipping email last week: the books are nicer than the emails, I promise.