Also try label:SPAM, is:spam, and broader queries with includeTrash.
Compare with an Inbox search.
Expected Behavior
search_threads returns the Spam threads so an agent can review Spam without using the browser.
Operating System
Other
Version Information
N/A — Gmail MCP connector issue; no Grok Bot version information available.
Additional Information
Actual: search_threads returns empty {} every time. Inbox search works, while list_labels still shows the Spam count.
Impact: cannot review or empty Spam via the connector for a query form the tool docs claim (in:spam / label:SPAM). Forced browser fallback.
Also filed via in-app Send Feedback and by email to [email protected] from [email protected] (thread subject: Grok Bot Gmail: search_threads returns empty for Spam while list_labels shows 3 threads).
The Gmail connector works on top of Google’s hosted Gmail server, and its search excludes Spam and Trash by default. The includeTrash option only adds Trash, and in:spam / label:SPAM / is:spam don’t override that default. That’s why you get an empty result even though list_labels still shows a count.
The documented way to reach Spam is the in:anywhere operator. Can you try it and tell me what you get back?
Ask the bot to call search_threads with this exact request: in:anywhere label:SPAM
If it’s empty, try search_threads with: in:anywhere is:unread your 3 Spam threads are unread, so they should show up with the SPAM label id
Reply here with whether step 1 or step 2 returned threads, or if it’s still empty.
One expectation note: the connector can move threads to Trash or Spam and change labels, but Google’s server doesn’t expose a permanent delete tool. So you can’t “clear” Spam through the connector right now, even once the threads are found.
Let me know what in:anywhere shows, since the next steps depend on that.
search_threads query in:anywhere is:spam (and with includeTrash) → empty {}.
search_threads query in:anywhere is:unread → returns unread threads (inbox), works.
Caveat: list_labels SPAM is threadsTotal=0 / threadsUnread=0 right now, so an empty Spam search is expected today and doesn’t re-prove the original gap. When I filed, list_labels showed threadsTotal=3 / threadsUnread=3 and every spam query including in:spam / label:SPAM returned empty while inbox search worked. That mismatch is still the bug (email T-F54576). Happy to re-run the in:anywhere tests the next time Spam has mail again.
Noted on permanent delete: understood.
Thanks for testing both options and catching the nuance. You got it right.
Since list_labels currently shows SPAM with threadsTotal=0 / threadsUnread=0, an empty response for a Spam request is expected and doesn’t really confirm the original issue. The fact that in:anywhere is:unread returned threads also confirms the connector itself is working fine.
To fully close this out, we need one conclusive run exactly when there are emails in Spam again. At that moment, please call search_threads with this exact request:
in:anywhere label:SPAM
This operator is documented on the hosted Gmail server as the way to reach Spam and Trash, unlike in:spam / label:SPAM / is:spam / includeTrash, which don’t override the default behavior. Please reply here with whether it returns those threads or still returns {}. The next steps depend on that.
On permanent delete, yep, that’s correct. The connector can move items to Trash or Spam and change labels, but Google doesn’t expose a tool for permanent deletion, so we can’t clear Spam through the connector right now.
search_threads with includeTrash=true and query in:anywhere label:SPAM → empty {}.
search_threads query in:anywhere is:unread → returns normal unread inbox threads (works). The Spam thread is not among them.
So with Spam non-empty, Dean’s documented in:anywhere path still cannot list Spam. Same mismatch as the original report (email T-F54576). Browser Gmail still shows the Spam thread.
Thanks for seeing it through and running the final test with a non-empty Spam folder. That was the conclusive run we were missing.
The outcome is clear. With list_labels, SPAM shows threadsTotal=1, but the documented request in:anywhere label:SPAM and all other Spam variants still return {}. At the same time, in:anywhere is:unread works and the thread is visible in the Gmail browser UI. So this isn’t about your setup or the connector itself. The behavior is on the hosted Gmail server side that the connector talks to directly. We pass arguments as-is, without rewriting the request or filtering the results.
I’ve shared this with the team along with your steps, so we can raise it upstream. I can’t share a timeline yet, but I’ll post here if there’s an update.
On permanent delete, it’s as discussed. The connector can move threads to Trash or Spam and change labels, but Google doesn’t expose an API for final deletion. So we can’t “clear” Spam through the connector right now. Until Spam search works, using the browser fallback is still a workable workaround for reviewing Spam.
Thanks Dean. Confirmed on my side just now (2026-09-10 ~4pm America/Toronto): search_threads with in:anywhere label:SPAM is still empty {}. We’ll keep using the browser fallback for Spam review until the hosted Gmail server side is fixed. Appreciate you raising it upstream and posting when there’s an update.
search_threads with includeTrash=true and query in:anywhere label:SPAM → empty {}.
Same mismatch as the Sep 8 conclusive run, the Sep 13 retest (forum reply was blocked that day by a signed-out browser), and the original report. Browser Gmail still shows the Spam threads. Still using the browser fallback until the hosted Gmail server side is fixed. Happy to retest when there is an update.
Thanks for running another retest, Aviv. The result matches the conclusive run from September 8 and the follow-up checks. When Spam isn’t empty (list_labels = threadsTotal 2), the documented in:anywhere label:SPAM still returns {}, while in:anywhere is:unread works and the emails are visible in the Gmail web UI. So this looks like hosted Gmail server behavior, not something in your setup or the connector.
No more runs are needed for now. The behavior is stable and has already been shared with the team for upstream escalation. I can’t share an ETA, but I’ll reply here as soon as there’s an update. Until server-side Spam search starts working again, the Gmail web fallback is still a working way to view Spam.
If you notice any meaningful change in behavior on your next check, let me know and I’ll add it to the current data.
Thanks Dean. Understood. Standing down on further retests unless Spam search behavior changes. Browser fallback stays in place until the hosted Gmail side is fixed. Appreciate you escalating upstream and posting when there’s an update.
I am also requesting same gmail spam access from grok bot for spam header analysis and spam filter updates.
(Lest anyone things Aviv is alone in this.)
My Grok Bot would like to clarify the following:
= = = =
Dean — the default hide of SPAM/TRASH is Google’s. The gap is still on this connector.
Google’s users.threads.list / users.messages.list already document two opt-ins that return Spam:
• includeSpamTrash=true
• labelIds=SPAM
This tool only exposes includeTrash plus q=. That is why in:spam, label:SPAM, is:spam, and in:anywhere label:SPAM all return {} while list_labels still shows a Spam count.
in:anywhere is a Gmail search-box operator. It is not a substitute for those two list parameters. On the API, q= still omits Spam unless one of those flags is set.
So: not a bad login, not an empty folder. Google’s hosted API can list Spam. This MCP wrapper never sends the parameter that asks for it. Please expose includeSpamTrash and/or labelIds (including SPAM) on search_threads / list.
Hey Talos, thanks for the detailed write-up and for confirming you’re not the only one running into this.
You nailed the technical detail. in:anywhere is a search string operator, and it’s not equivalent to the list parameters includeSpamTrash=true or labelIds=SPAM that Google documents for users.threads.list and users.messages.list. I shared this exact observation with the team. The connector currently only passes through includeTrash plus q= and doesn’t set those two parameters for search_threads. This is a useful angle, separate from what we discussed with Aviv above.
The issue is already being tracked. I can’t share an ETA yet, but I’ll reply in the thread if there’s an update. For now, since server-side Spam search isn’t available through the connector, the browser fallback is still the working option to view Spam.
If you notice any change in behavior on your side, let me know and I’ll add it to what we have.
The search staff suggested didn’t work. Spam in the support inbox has 10 threads right now (9 unread, 12 messages), but in:anywhere label:SPAM came back empty. Since Spam wasn’t empty this time, that’s the conclusive test they asked for, and it confirms the bug.
Here’s a reply you can paste into the forum thread:
“Ran the conclusive test just now (Sep 27, 2:13 PM CT). list_labels showed SPAM with threadsTotal=10, threadsUnread=9, messagesTotal=12. In the same session, search_threads with the exact request in:anywhere label:SPAM returned {}. So the connector still can’t see Spam threads even while Spam has mail in it.”
Nothing was changed in Gmail. Both checks only read the inbox.
In Grok Bot, the Gmail connector can’t see or act on messages in the Spam folder. When I asked my assistant to delete the spam in our support inbox, it searched and reported the folder as empty. Gmail itself showed 9 messages in Spam for the same account. Searches with in:spam, label:SPAM, and in:anywhere all return an empty result, even when searching for an exact sender that’s sitting in Spam. Search works normally for the inbox and all other folders. Because the empty result looks like “no mail,” the assistant gave me wrong information
Steps to Reproduce
Connect a Gmail account to a Grok Bot assistant through the Gmail connector.
Make sure the account has messages in Spam (confirm in the Gmail web app).
Ask the assistant to list or delete the messages in Spam.
The connector’s search comes back empty for in:spam, label:SPAM, and in:anywhere, so the assistant can’t find or delete them.
Expected Behavior
The connector should be able to list Spam messages and trash or delete them, perhaps through an includeSpam option like the existing includeTrash. At minimum, it should return a clear message that Spam is excluded, not an empty result that looks like “there’s nothing here.”
Operating System
Windows 10/11
Version Information
Grok Bot 0.61.0
For AI issues: which model did you use?
Grok Bot
For AI issues: add Request ID with privacy disabled
N/A
Additional Information
This happened on Sunday, Sep 27, 2026, around 12:30 PM CT, in a Grok Bot assistant connected to a Google Workspace Gmail account. The same connector finds messages in the Inbox, Sent, Drafts, and custom labels without trouble, and it can see Trash when its includeTrash option is turned on. Only Spam is invisible. Even a message we had given our own “Vendor pitch” label disappeared from search once Gmail moved it into Spam. What makes it confusing is that an empty result looks the same as “nothing here,” so the assistant told me my Spam folder was empty when it had 9 messages in it.
Hey Wes, thanks for the conclusive run. That’s exactly the kind of run we needed, with non-empty Spam. Your result (SPAM threadsTotal=10, and in:anywhere label:SPAM returning {}, while the emails are visible in the web UI) fully matches what we’re already tracking in this thread.
You and Talos correctly caught the nuance: in:anywhere is a search string operator, and it doesn’t replace the list parameters includeSpamTrash=true or labelIds=SPAM that Google documents for users.threads.list. I shared that angle with the team separately, it’s useful.
I can’t share an exact date yet, but I’ll reply in the thread as soon as there’s an update. For now, server-side search in Spam via the connector isn’t available, so the working option to view Spam is the Gmail web fallback. And as discussed above: the connector can move emails to Trash or Spam and change labels, but Google doesn’t provide a tool for permanent delete, so we can’t “clear” Spam via the connector right now.
If you notice any change in behavior on your side, let me know and I’ll add it to the current data.