claude-code - 💡(How to fix) Fix [BUG] Drive MCP create_file rejects valid base64 above ~11K chars with "not a valid base64 string" [1 comments, 2 participants]

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?

The Google Drive connector's create_file tool rejects valid base64-encoded .docx payloads above approximately 11,000–12,000 base64 characters with the error "The file content is not a valid base64 string." The base64 content is verifiably valid — it round-trips through base64 -d to produce a byte-identical, validly-structured .docx file. Smaller payloads using the same encoding pipeline succeed.

This appears to be the current manifestation of a previously reported bug ("[BUG] Drive MCP create_file silently truncates binary uploads around 10K base64 chars" in this repo). The underlying payload-size threshold seems unchanged, but input validation now produces an explicit error instead of silent truncation.

This blocks any agentic workflow that needs to write .docx, .xlsx, .pptx, or other binary office files to Drive — even small, formatted business documents. A typical Word document with a single table and a few paragraphs already exceeds the threshold.

What Should Happen?

create_file should successfully upload any base64 payload that decodes to valid file bytes within reasonable size limits. Google's underlying Drive API supports resumable uploads natively (https://developers.google.com/drive/api/guides/manage-uploads#resumable) and handles multi-megabyte direct uploads without issue. The connector's payload validation should not reject content well within the documented 30MB Claude.ai upload ceiling.

Suggested fix directions:

1. Switch the connector to use Drive's resumable upload API for any payload above some safe threshold (e.g., 256 KB), invisible to the caller.
2. Raise the validation limit, since the underlying Google Drive API can comfortably handle multi-megabyte direct uploads.
3. Surface a chunked_content parameter or a separate create_file_chunked tool for callers who need to upload binaries above the current threshold.

Error Messages/Logs

Error returned by Google Drive:create_file:

  The file content is not a valid base64 string.

  request_id: req_011CaVFQDAdsrtsxV7ipEeRm

(Multiple request_ids observed across retries with identical error.)

Pre-upload verification (passed):
- File: Nicole Matthews 1on1 - 2026-04-27.docx
- File size on disk: 11,673 bytes
- Magic bytes: PK\x03\x04 (valid ZIP/OOXML signature)
- Base64 length: 15,564 chars (no whitespace, single-line, produced via `base64 -w 0`)
- Round-trip test: `base64 -d encoded.b64 > test.docx && diff -q file.docx test.docx` reports files match
- File validates via python-docx and opens correctly in Word/Google Docs after manual upload

Comparison case (succeeded):
- File: 8,569-byte .docx generated via the same docx-js pipeline
- Base64 length: 11,428 chars
- Same MIME type, same parent folder, same encoding flags
- create_file returned success with valid Drive file ID

The threshold sits between 11,428 and 15,564 base64 characters.

Steps to Reproduce

Environment:

• Claude.ai web app (consumer)
• Google Drive connector enabled and OAuth-authorized
• Code execution / sandbox available
• Date observed: April 27, 2026

Steps:

1. In a Claude.ai chat session, generate a small .docx file using docx-js with: a title, a 5-row table with cell shading, ~6 paragraphs of prose, three named styles (Heading 1, Heading 2, Normal). Resulting file size: ~11,673 bytes.

2. Base64-encode the file with no line wrapping: base64 -w 0 file.docx > encoded.b64 Resulting base64 length: ~15,564 chars.

3. Verify the encoding round-trips correctly: base64 -d encoded.b64 > test.docx diff -q file.docx test.docx Output: files match.

4. Call Google Drive:create_file with these arguments:

   • content: the 15,564-char base64 string from step 2
   • mimeType: application/vnd.openxmlformats-officedocument.wordprocessingml.document
   • parentId: any valid folder ID
   • title: any string

5. Observe the error: "The file content is not a valid base64 string."

6. To confirm the threshold, repeat steps 1–4 with a smaller .docx (~8,569 bytes / ~11,428 base64 chars). The smaller file uploads successfully under identical conditions.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

Claude Opus 4.7

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Severity / impact

• Production blocker for any Skill or agent workflow that produces formatted .docx, .xlsx, or .pptx output destined for Drive
• Affects small, ordinary business documents — not edge-case large files. A single-table Word doc with ~6 paragraphs already exceeds the threshold
• The error message ("not a valid base64 string") is misleading — it suggests user encoding error when the actual cause is server-side payload size limits. Cost me significant debugging time before identifying the real cause via web research

Other connectors not affected

• Google Drive:create_file with text content (markdown, plain text, HTML) succeeds at much larger payloads
• Google Drive:read_file_content and download_file_content work fine for the same .docx files when uploaded through the Drive web UI
• The threshold appears specific to the binary upload path inside create_file

Suggested error message improvement (regardless of root-cause fix)

If the underlying limit isn't immediately raised, the error message should at minimum be honest:

• Current: "The file content is not a valid base64 string."
• Better: "File payload exceeds the connector's size limit. Try a smaller file or reduce binary content size."

This would save users from chasing an encoding red herring.

Reference: known related issue in this repo

Earlier report (silent-truncation variant of same root cause): "[BUG] Drive MCP create_file silently truncates binary uploads around 10K base64 chars" — same threshold, different surface symptom (silent truncation then; explicit rejection now).

Confirmed working comparison: text upload at much larger payload

A 50KB+ markdown file uploads successfully via the same create_file tool with mimeType: text/markdown. Suggests the limit is in the binary-upload code path specifically, not a global request-size cap.

Open MCP spec proposal worth noting

modelcontextprotocol/modelcontextprotocol#1306 (SEP-1306: Binary Mode Elicitation for File Uploads) explicitly identifies the broader problem: "Currently, these scenarios require workarounds such as: complex base64 encoding within text fields (inefficient, size-limited)." This bug is a concrete instance of that documented limitation.

Use case context

I'm building an automated meeting-notes pipeline: transcript ingest → formatted .docx generation → Drive upload → Google Apps Script auto-conversion to native Google Doc → Slack notification. The Drive upload step is the only step currently blocked. All other connectors (Calendar, Slack, Fireflies, Zoom) work reliably at the payload sizes I'm pushing through them.