›_ Claude Code Issues
Claude Code Issues / #53442

[BUG] Cowork Google Drive MCP cannot see content in any Workspace Shared Drive

Open 💬 28 comments Opened Apr 26, 2026 by jwshrive

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Repo: anthropics/claude-code
Component: mcp-google connector (Cowork built-in) — also reproduced against the official drivemcp.googleapis.com/mcp/v1 connector
Connector version observed: mcp-google v0.1.0, commit dev, build date 2026-04-24T09:52:04.561Z
Environment: Cowork mode (research preview), Windows 11 desktop client

Summary

The Drive connectors silently omit the Google Drive v3 API parameters required to surface Shared Drive content. As a result, any user whose data lives in a Workspace Shared Drive (i.e. most business, club, and team accounts) cannot reach that content from Cowork — drive_list_files, drive_search_files, and drive_get_file return empty results or 404 Not Found instead of the actual files. The user's "My Drive" works fine, which makes the failure mode hard to spot at first.

Reproduction

Account: a Google Workspace account that is a member of one or more Shared Drives.
Step 1 — confirm that personal My Drive works
drive_list_files(folderId='<MY_DRIVE_ROOT_ID>') → returns folders/files as expected
Step 2 — try a Shared Drive root
drive_list_files(folderId='<SHARED_DRIVE_ROOT_ID>') → returns { files: [] } ← bug
Step 3 — try direct lookup of the Shared Drive root
drive_get_file(fileId='<SHARED_DRIVE_ROOT_ID>') → MESSAGE_NOT_FOUND "File not found: <SHARED_DRIVE_ROOT_ID>" ← bug
Step 4 — try searching for known content inside that drive
drive_search_files(query="'<SHARED_DRIVE_ROOT_ID>' in parents") → returns { files: [] } ← bug
drive_search_files(query="name = '2026 Committee' and mimeType = 'application/vnd.google-apps.folder'") → returns { files: [] } ← bug, even though the folder exists and the user has access

The same four calls against the user's My Drive root (a 0A... ID returned by drive_get_file with name "My Drive") all succeed, which proves the auth and account routing are correct.

Root cause

The Google Drive v3 API requires three flags to include Shared Drive content in files.list and files.get:
supportsAllDrives=true includeItemsFromAllDrives=true corpora=allDrives # or corpora=drive&driveId=<id> for a specific Shared Drive

Without those, the API scopes the request to the user's "user corpus" (My Drive + sharedWithMe). Crucially, when a Shared Drive ID or a file inside one is referenced, the API does not return an auth error — it returns an empty list or 404. That makes the failure look like a permission problem when in fact it's a missing query parameter.

Reference implementations that handle this correctly: a-bonus/google-docs-mcp passes both supportsAllDrives and includeItemsFromAllDrives on every Drive operation (files.list, files.get, files.create, files.update, files.copy, files.delete, permissions.create).

Expected behaviour

drive_list_files, drive_search_files, drive_get_file, and any related tools should pass:

  • supportsAllDrives=true — on all operations
  • includeItemsFromAllDrives=true — on files.list style operations
  • corpora=allDrives by default for searches, or accept a driveId argument to scope to a specific Shared Drive

Actual behaviour

Shared Drive content is invisible. Users see folders and files in the Drive web UI but the connector cannot see them. There is no error indicating why — just empty results.

Impact

Severe for any Workspace customer using Shared Drives. In my session I was trying to:

  • Locate the latest committee meeting minutes for a sporting club — stored in Committee Shared Drive
  • Cross-reference financial reports — stored in Finance Shared Drive
  • Pull policy documents — stored in Policies And Governance Shared Drive

None of those drives are reachable. Only the secretary account's personal My Drive works. The Drive for Desktop workaround is not viable on Windows because Cowork's directory mount cannot traverse drive-letter mappings.

Notes on the second connector

The session also has the official Google Drive connector (drivemcp.googleapis.com/mcp/v1) connected. It exhibits the same flag-omission behaviour (get_file_metadata on a Shared Drive ID → "Requested entity was not found"; search_files with parentId='<SharedDriveId>' → empty). Whether that's a separate bug in the Google-hosted connector or a downstream wrapper is unclear, but the symptom is identical, so this fix should ideally be coordinated across both.

Related but distinct issues

  • #33590 — Drive for Desktop folder access (path/mount issue, not the API flag issue)
  • #30457, #39422, #40294, #41635, #41660 — connector availability/passthrough between claude.ai and Claude Code

None of those cover the missing API parameters reported here.

What Should Happen?

drive_list_files, drive_search_files, drive_get_file, and any related tools should pass supportsAllDrives=true, includeItemsFromAllDrives=true, and corpora=allDrives by default, so that Shared Drive content is visible alongside My Drive content.

Error Messages/Logs

Steps to Reproduce

  1. Sign into Cowork with a Google Workspace account that has access to one or more Shared Drives.
  2. Call drive_list_files(folderId='<SHARED_DRIVE_ROOT_ID>') — returns { files: [] } (expected: list of files/folders).
  3. Call drive_get_file(fileId='<SHARED_DRIVE_ROOT_ID>') — returns MESSAGE_NOT_FOUND (expected: drive metadata).
  4. Call drive_search_files(query="name = 'KnownFolder'") — returns { files: [] } (expected: matching folder).
  5. Repeat steps 2–4 using the user's My Drive root — all return correct results, confirming auth is working.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

mcp-google v0.1.0, commit dev, build date 2026-04-24T09:52:04.561Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

28 Comments

johnstruckmann-cyber · 2 months ago

this is still an issue, please resolve ASAP!

luff-mitchell · 2 months ago

I am also experiencing this issue. Please fix it as soon as possible. I don't want to waste any more tokens on this.

pskoric · 2 months ago

+1, also an issue that's been driving me crazy, pls fix

paulscottnz-cp · 2 months ago

Same issues, could an update please be provided when it will be fixed?

pixelloop · 2 months ago

Having this issue myself. It's annoying because I'm the owner of the shared folder, which means I have to have Claude save files in my root folder or elsewhere, and then I have to move them myself. Hopefully, the MCP gets updated soon.

julienlev99 · 2 months ago

We are only using Shared Drive and this issue limits the quality on how we can ship some use cases. I would love to see Shared Drives being supported!

danielxeal · 2 months ago

Please fix this issue, it blocks the main advantage Claude Code has over others.

FranArjona · 2 months ago

Also experiencing the same issue, hoping it is fixed soon as it is blocking us.

Basim108 · 2 months ago

same here. +1 for a fix.

edl-bb · 2 months ago

+1 for a fix please 🙏

jliurner · 2 months ago

+1

enktech · 1 month ago

If only there was some kind of smart tool that could be used to analyze code bugs like this and come up with a solution in a timely manner!
Code in desktop can work with my shared folder but Cowork can't (but sometimes, in some circumstances can).
Fix it already would ya!

daniela-vita-Cyera · 1 month ago

still an issue, waiting on resolution

mgoward · 1 month ago

This is a major issue, how do we get this escalated?

trjw · 1 month ago

This is basically a showstopper for enterprise use of Claude - how do we escalate this?

dkallen · 1 month ago

This is important as most of our business data lives in shared drives and this makes it hard for Claude to ingest it.

causehacker · 1 month ago

Seeing the same. my workaround is to temporarily have a process that copies necessary files to a Drive folder (from the shared drive) and update my Skills to reference this until fixed

dkallen · 1 month ago

Thank you, @causehacker . This will work for some of my scenarios, so I'll try it.

bhumikau-commits · 24 days ago

I shared the folder from 'My Drive' with everyone, yet it still throws this goofy 'no documents available' nonsense. I had to go full keyboard warrior down a rabbit hole just to discover issue #53442 on GitHub. It’s been sitting there open for a solid month with 20+ users reporting the exact same thing, completely ignored. Absolutely love spending my days manually moving files around because basic query parameters are apparently too hard to implement. Truly thrilling times. 💀

michaelpelser-uptempo · 23 days ago

+1

using the official drivemcp.googleapis.com/mcp/v1 connector (macOS Cowork).

for me the Shared Drive root lists fine - search_files(parentId=<driveRootId>) returns all child folders, nested folders returns {}.

Looks like the connector only does the shared-drive handling (corpora=drive&driveId=) when the parent is the drive root, and falls back to the user corpus for nested folders.

Reading by file ID works, but there's no way to discover the IDs.

cjenkins-itegrity · 22 days ago

+1 I am also experiencing this issue.

michaelpelser-uptempo · 22 days ago

I was able to resolve this issue, there was an AI-eligibility flag that was disabled, once that flag was switch to enabled I am now able to see all the files in the folder

cjenkins-itegrity · 22 days ago
I was able to resolve this issue, there was an AI-eligibility flag that was disabled, once that flag was switch to enabled I am now able to see all the files in the folder

Can you share what flag that was? I have been through all the configurations I can think of and don't see anything I could change to resolve this.

dkallen · 22 days ago

and does that AI-eligibility flag affect ALL shared drives, or is it a
setting on each Shared Drive?

Thank you,
David Kreth Allen
612-374-1119
762 California Ave W, St Paul, MN 55117

On Wed, Jun 24, 2026 at 10:09 AM cjenkins-itegrity @.***>
wrote:

cjenkins-itegrity left a comment (anthropics/claude-code#53442) <https://github.com/anthropics/claude-code/issues/53442#issuecomment-4790732164> I was able to resolve this issue, there was an AI-eligibility flag that was disabled, once that flag was switch to enabled I am now able to see all the files in the folder Can you share what flag that was? I have been through all the configurations I can think of and don't see anything I could change to resolve this. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/53442?email_source=notifications&email_token=ABTCATQQA3E2L4DSTDTPFIL5BPVMHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZZGA3TGMRRGY2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4790732164>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTCATXQXFFITOSELRDMCCT5BPVMHAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMZTGAYDQOJXGYZ2C5QC> . You are receiving this because you commented.Message ID: @.***>
hannes-ceezer · 20 days ago
I was able to resolve this issue, there was an AI-eligibility flag that was disabled, once that flag was switch to enabled I am now able to see all the files in the folder

@michaelpelser-uptempo please let us know. we checked the settings and didn't find one that did it for us.

michaelpelser-uptempo · 20 days ago

Sorry I don't have a ton of info - per my internal IT, "A google admin has to approve Claude for Google Drive. Just needs to be approved for the org". I was already able to use Google Drive with Claude, but before they did this I was seeing the same issue from this thread (could not see documents in a folder within a shared drive), afterwards it was fixed.

brentsmi · 15 days ago
Sorry I don't have a ton of info - per my internal IT, "A google admin has to approve Claude for Google Drive. Just needs to be approved for the org". I was already able to use Google Drive with Claude, but before they did this I was seeing the same issue from this thread (could not see documents in a folder within a shared drive), afterwards it was fixed.

Are you certain you can see all files in all shared drives, or just files from shared drives that you have opened previously?

tthiadens-TT · 14 days ago

Summary

The Google Drive connector silently returns empty/no results for content that
demonstrably exists in a Google Workspace Shared Drive. The failure is
silent: no error, no warning. An empty result is indistinguishable from
"the folder is genuinely empty" or "the file does not exist." That silent nature
is the core problem — it is more damaging than an outright error, because it
produces confident, wrong conclusions.

This looks related to #53442 but is broader: it affects not only folder
listing (parentId) but also content search (fullText / title).

Environment

  • Claude Code, Anthropic-hosted Google Drive connector.
  • Target: a Google Workspace Shared Drive (not "My Drive").
  • Ground truth established via a Google service account (Drive API v3 with

supportsAllDrives=true, includeItemsFromAllDrives=true, corpora=drive).
The service account reads the same Shared Drive completely and correctly,
which is how we know the connector's empty results are false.

Observed behavior

  1. search_files with parentId = '<subfolder>' on a Shared Drive folder

returns subfolders but silently hides files (verified against a service
account listing of the same folders). A folder containing only files appears
completely empty (e.g. a folder with 54 files returns {} or a bare
nextPageToken); a folder that contains subfolders appears to work while all
of its files stay hidden. No error is returned in either case. This makes the
bug look folder-specific when it is in fact universal.

  1. list_recent_files never returns individual Shared Drive files, only folders.
  2. fullText / title search returns false negatives on Shared Drive

content. Example: a 41 KB markdown file that provably exists in the Shared
Drive (confirmed via service account) was not returned by
fullText contains '<distinctive string from that file>'.

  1. Reading a file by known fileId works; listing the Shared Drive root works.

So the connector partially handles Shared Drives (root + known-ID reads) but
fails on nested listing and on reliable search.

  1. A separate Drive tool, mcp__gdrive__search, fails on every input

(including a single character) with MCP error -32603: invalid_request.

Likely root cause (per #53442)

The connector omits supportsAllDrives / includeItemsFromAllDrives /
corpora on nested queries, silently scoping to the user corpus
(My Drive + shared-with-me), which excludes Shared Drive contents.

Impact

Because the failure is silent, it is indistinguishable from real emptiness. Over
multiple sessions this produced repeated wrong root-cause conclusions and, in one
case, an entire multi-agent investigation whose negative findings
("files missing / migration incomplete") were themselves artifacts of this bug —
reversed only after a service-account scan proved all content was present. This
cost very substantial time and token spend. Either correct Shared Drive handling,
or a clear error instead of a silent empty, would have prevented all of it.

Requested fixes (priority order)

  1. Send supportsAllDrives=true, includeItemsFromAllDrives=true, and the

correct corpora on all list/search operations, so Shared Drive content
surfaces the same way "My Drive" content does.

  1. If a query is scoped in a way that cannot include Shared Drives, return a

clear warning/error instead of a silent empty result. Silent false-negatives
are the worst possible failure mode for an AI agent.

  1. Fix mcp__gdrive__search returning -32603 on all inputs.
  2. Document Shared Drive support and current limitations in the Google Workspace

connector help article (Shared Drives are currently not mentioned at all).

Reference: #53442