Gmail connector: search_threads index lags days behind mailbox; search results embed stale thread views

Environment

• Claude Code CLI (macOS, Darwin 25.5), claude.ai Gmail connector (mcp__claude_ai_Gmail__* tools)
• Connector authenticated to a Google Workspace account

Summary

search_threads is served from an index that lags hours to days behind the actual mailbox. Recently delivered mail is invisible to every search variant, while get_thread / get_message by ID return it instantly and completely. This makes "find the email about X in my inbox" silently fail for exactly the mail users most often ask about — the recent kind.

Two distinct symptoms

1. Recent messages unsearchable. A message delivered on 27 Jul (labels IMPORTANT, INBOX) was still not returned by any search on 30 Jul — 3+ days later. Tried: from:<sender-domain>, exact keywords from the body, sender name, in:anywhere (incl. spam/trash). All empty. get_message with the known ID returns it fully (headers, body, attachments).
2. Stale thread views inside search results. For a thread that currently has 24 messages (latest received the same morning, confirmed via get_thread), every search_threads result renders the thread with only 5 messages ending 8 days earlier. The plain no-query listing (which the docs describe as "lists all threads") shows the same stale view and stale recency ordering — a thread with a same-day message does not sort to the top.

Repro (as observed; any active mailbox should do)

1. Receive an email (verify it in the Gmail web UI, INBOX).
2. Within the next hours-to-days, call search_threads with from:<sender> or distinctive body keywords → empty result.
3. Call get_thread on the containing thread (or get_message on the ID) → message present with full content.
4. Compare the message list search_threads embeds for that thread vs get_thread → search's copy is missing the newest messages.

Ruled out

• Not auth/scope: reads by ID work; older mail searches fine.
• Not delivery: messages confirmed in INBOX with correct labels.
• Not client-side: no local Gmail MCP config exists; behavior persists across connector disconnect/reconnect and across sessions.

Impact

Agents asked to "find the email from <vendor> yesterday" conclude the email doesn't exist. Users end up manually copy-pasting email content to the agent, which defeats the connector. The only workaround we found: locate the thread via older stable terms, then always get_thread for the live view — impossible for brand-new threads with no old anchor.

Expected

search_threads (and the no-query listing) should reflect the mailbox with at most seconds-to-minutes of lag, like Gmail's own search, or the tool docs should state the index freshness so agents can be prompted around it.