TLDR: include_body=True in an MCP email tool is great for a human-facing UI. For a headless daemon with a token cap, it's a bomb. Same flag. Different consumer. Different outcome entirely.

The Setup

I run a CEO briefing daemon — a launchd job (macOS's background task scheduler) that fires at 8 AM on weekdays, spins up a headless claude -p (no terminal, no GUI), reads my email via the Arcade MCP (my email/auth middleware) and my tasks from Things 3, and drops a fully-formed briefing project into Things with action items and Superhuman deep-links. Completely autonomous. I love it.

In May, I fixed a real bug in the Arcade MCP email formatting layer. The tool was calling format_email_list with include_body=False — meaning every email came back as a 300-character snippet, totally truncated. I flipped it to include_body=True, bodies came through, and everything looked great.

What Broke

June 16th. The daemon hung for 300 seconds. Then timed out. Tried again. Hung again. Gone.

What I Tried First (And Got Wrong)

I chased two dead ends.

First: A new Claude build had shipped overnight — maybe a compatibility issue?

Second: I landed on TCC (macOS's privacy permission system, the thing that controls app access to Mail, Calendar, Files). Claude had auto-updated to 2.1.178. New binary, no grants yet. Surely that was it.

I even offered to build the briefing right there in the terminal and paste it into Things manually.

I shut that down immediately: "Don't skirt around solving problems. The CEO brief you create in this terminal is useless if an agent can't do it on its own. Get this sorted."

Fair. Back to the root cause.

How I Knew I Was Wrong

The tell: I ran a streamed version of the exact same daemon invocation with --verbose — full grant access, Full Disk Access granted, TCC totally clean.

It still hung.

That ruled out TCC entirely. Something else was happening inside the tool call itself.

The Actual Problem

That morning was a "Big Wins" email blast across my ecommerce business and two other business accounts. 146 unread emails. With include_body=True and max_results=100, the get_unread_emails call pulled FULL bodies on all of them.

Over 1,000,000 characters of email text.

That blew past the MCP tool-output token cap and spilled into a sidecar file. The headless deepseek-v4-pro:cloud model (my Ollama-hosted reasoning model) couldn't reliably re-parse the spillover. It just… thrashed. Burned the whole watchdog window. Died.

Same include_body=True flag that made my dashboard rich and readable — the one I was proud of shipping in May — was the thing killing my daemon. Same flag. Different consumer.

The Fix

Controlled body inclusion in daemon contexts. Plus two secondary fixes that were real contributors:

  • AppleScript timeout: wrapped the Things 3 tell block in with timeout of 600 seconds (the default 120s ceiling was dying during iCloud sync)
  • TCC stability: froze the Claude autoupdater with DISABLE_AUTOUPDATER=1 + Full Disk Access — not the primary killer, but a real operational risk for any headless daemon touching gated resources

Proof it worked: canceled:0 → CEO_BRIEFING_DELIVERED::2026-06-16 → verify count:1|notes:9982|todos:9 → RESULT: OK. Nine action items. Full digest. Delivered autonomously.

Why This One Stuck With Me

A scrolling human wants full email bodies. A token-capped headless model does NOT.

Match your verbosity to who's consuming the output — not to what looks complete when you're looking at it interactively. What's "more complete" for one consumer is catastrophic for the other. That's the thing I'd do differently from the start.

P.S. The two red herrings (Claude build, TCC) weren't dumb guesses — they were plausible. The thing that broke the case was running the daemon with all the suspected culprits eliminated and watching it still fail. You can't skip that step.