[FEATURE] Google Drive connector: no way to update an existing file's content (update_file is metadata-only), so revisions require a browser
Summary
The Google Drive connector can create files with content (create_file, with textContent / base64Content) but there is no way to replace the content of a file that already exists. update_file accepts only title and parentId — its own description says "currently only title and parent_id are supported".
The Drive API supports this: PATCH https://www.googleapis.com/upload/drive/v3/files/{fileId}?uploadType=media creates a new revision in place, keeping the file id and the version history. The connector holds the OAuth token that could make that call; nothing in the tool surface exposes it.
Why it matters
Keeping the file id stable is the whole point. Every link to that file — a calendar event description, a Google Chat smart chip, a shared bookmark, an email someone already sent — points at the id. Today the only options a session has are:
- Create a second file and repoint every link by hand, leaving a duplicate behind, or
- Drive a real browser session to File → Manage versions → Upload new version.
Option 1 produces exactly the clutter users object to. Option 2 needs a logged-in browser and a local file input, so when browser automation is unavailable the revision simply cannot happen, even though the connector is authenticated and working.
Concrete case
A briefing document lives in a shared Drive folder and is linked from a Google Calendar event. Revising it should be one new revision of that file. Instead it required uploading a new file, editing the calendar event to the new id, and removing the old one — and when the browser route was down, the corrected version could not be applied at all.
Requested
Either:
- extend
update_fileto accepttextContent/base64Content+contentMimeTypeand issue the mediaPATCH, or - add a separate
update_file_contenttool.
Ideally also expose keepRevisionForever and let revisions.list be read, so a session can confirm the new revision landed.
Related
Not a duplicate of #30457 (connector connected but tools not exposed) — the tools are exposed and working here; the write verb is the gap.
3 Comments
+1 — this blocks real document-governance workflows.
Use case: I maintain a Markdown-based company records system in Google Drive (a router index plus ~50 canonical records). Every record is referenced by its stable Drive file ID from indexes, calendar events and other documents. Updating a record must keep the same file ID and preserve revision history. With update_file limited to title/parentId, Claude can only create a new file (new ID, breaking every reference) or fall back to a locally mirrored Drive folder via Drive for Desktop.
The same workflow works today in ChatGPT's Drive integration. Adding textContent/base64Content + contentMimeType to update_file (media PATCH on files.update), ideally with keepRevisionForever and revisions.list, would close the gap. Reproduced on 2026-09-21 in Claude Cowork (desktop, Windows).
Also hitting this on Windows 11 Pro (Claude desktop 2.16120.0.0), 2026-09-30. Every content change to an existing file becomes rename + create. With Google Drive for Desktop syncing the same folder, that leaves
(1)/(2)copies of the canonical filename locally, and any other session holding the old file ID now points at the renamed original.+1, hitting this in a small business sales workflow, in more than one place.
In both cases the connector is authenticated and can read the files fine; it just can't write a new version back. Being able to push new content to an existing file (media PATCH on files.update, keeping revision history) would remove the manual step entirely.