Reach files in shared drives from the Google Drive connector

[kevin9327]

What this changes

Google's shared drives guide lists files.get and files.list among the methods that need supportsAllDrives=true before they will handle shared drive items. For listings it adds, on includeItemsFromAllDrives:

Whether both My Drive and shared drive items should be included in results. If not present or set to false, then shared drive items are not returned.

None of the Drive connector's requests send either parameter:

Tool	Request	What a file in a shared drive got
get_file_metadata	files.get	Google Drive refused this request (404): File not found: …
read_file_content	files.get for the type, then alt=media or export	the same 404 on the first request, so nothing is read
search_files, list_recent_files	files.list	not returned

So a Bot with the connector granted could not read a document the person asking can open, whenever it sits in a shared drive, which is where many Workspace organisations keep their documents. The connector's docs say it reads Drive as the person asking, and the failure reads as a missing file rather than a missing parameter.

After this change:

• files.list sends supportsAllDrives=true&includeItemsFromAllDrives=true. corpora is left at Drive's default user, which the guide recommends over allDrives. Listings gain the shared drive files that corpus covers and nothing broader.
• Each files.get (the metadata lookup, read_file_content's type lookup and its alt=media download) sends supportsAllDrives=true.
• files.export is unchanged. Its only parameter is mimeType.

Nothing else changes: the fields asked for, how results are formatted, what is refused, and the scope (drive.readonly). A My Drive file is answered exactly as before. For files outside shared drives the parameter says only that the client can handle both kinds.

This touches the same file as #588 (the trash filter), in separate hunks. I merged the two branches locally: the source and the test file auto-merge, and all 21 cases pass. Only CHANGELOG.md conflicts.

Where it runs

• New state that outlives a request? None. This only adds query parameters to requests sent to Google.
• What happens on the second replica? The same requests.
• Anything serialised? No.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Every acting call still goes through the gateway: resolve, decide, audit, then act. Grants, policy and the audit row around callTool are untouched.
• New refusals and new failures each write a row. None are added.
• Nothing new is trusted from the client that the server can resolve itself. Drive still decides what the person's token can see. This only stops the connector from asking Drive to hide shared drive files.

Changelog

• A line in CHANGELOG.md under Unreleased.

Proof

A new describe block in server/tests/google-drive-rest.test.ts uses the file's existing stubFetch and asserts the parameters on every request each tool makes: both listings, the metadata lookup, and both requests of a text-file read.

With google-drive-rest.ts from main (only the tests added):

Expected: "true"
Received: null
(fail) a file in a shared drive is reached like one in My Drive > both listings ask Drive for shared drive items
Expected: "true"
Received: null
(fail) a file in a shared drive is reached like one in My Drive > looking a file up says the caller supports shared drives
Expected: "true"
Received: null
(fail) a file in a shared drive is reached like one in My Drive > reading a file says so on the lookup and on the download
 18 pass
 3 fail

With the fix:

• bun test --coverage server/tests/google-drive-rest.test.ts: 21 pass, 0 fail. The existing 18 are unchanged, including the exact q and orderBy assertions. The only uncovered lines in google-drive-rest.ts are 175–181, the network-error branch of request, which this change does not touch.
• bun run typecheck (app, server, worker): exit 0. bunx biome check and biome lint --error-on-warnings on the changed files: clean.

I have no Google Workspace account wired to a deployment here, so this was not driven against live Drive. The behaviour it fixes is the one Google's guide documents above, and the tests pin the parameters this connector now sends.

This PR adds its entry at the top of ## Unreleased, where other open PRs add theirs, so the changelog may conflict. I can rebase if it does.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[davidmckayv]

Code-verified clean; CI green on this sha.