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

[jwshrive]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• 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= 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

• Claude Co-Work Cannot Access or Modify Files in Google Drive Directory — Limited to Home Directory Only #33590 — Drive for Desktop folder access (path/mount issue, not the API flag issue)
• [BUG] Google Drive connector shows connected but tools not exposed in Cowork #30457, Google Drive MCP connector not passed through to Claude Code #39422, [BUG] Don't have access to Google Drive in Claude & Claude Work - even though it's Connected in UI #40294, [Bug] Google Drive integration not implemented in Claude Code connector #41635, Google Drive connector connected in claude.ai but not available in Claude Code sessions, despite Gmail and Google Calendar working. #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

[johnstruckmann-cyber]

this is still an issue, please resolve ASAP!

[luff-mitchell]

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]

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

[paulscottnz-cp]

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

[pixelloop]

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]

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]

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

[FranArjona]

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

[Basim108]

same here. +1 for a fix.