[BUG] Google Drive MCP connector — create_file with explicit parentId fails "User cannot add children to specified folder" — regression after May 7 incident

[daisyadmin]

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 returns "User cannot add children to the specified folder" when any explicit parentId is specified. This was working correctly before May 7, 2026 and has since regressed.

Writing with no parentId (defaults to Drive root / My Drive root) succeeds. Writing with any explicit folder parentId — including freshly created test folders — fails with the same error. Revoking OAuth at myaccount.google.com/permissions and reconnecting the connector did not fix it.

What Should Happen?

Files created with an explicit parentId should land in the specified folder, as they did prior to May 7, 2026.

Error Messages/Logs

Steps to Reproduce

1. Connect Google Drive connector in claude.ai Settings → Connections
2. 2. In a claude.ai chat, ask Claude to create a file in a specific folder (any folder in My Drive)
3. 3. Observe error: "User cannot add children to the specified folder"
4. 4. Ask Claude to create a file with no parentId specified — this succeeds and lands in Drive root
5. 5. Repeat step 2 with a brand new folder created seconds earlier — same error

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A — this is the claude.ai web connector (not Claude Code CLI)

Claude Code Version

N/A — this is the claude.ai web connector (not Claude Code CLI)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Connector: Google Drive (claude.ai Settings → Connections)
• • Was working: confirmed 14 clean writes to specific parentIds on May 7, 2026 before the incident
• • • Stopped working: during/after the May 7 platform outage (15+ hours down per StatusGator)
• • • • Write to root (no parentId): WORKS — returns file in parentId 0AIp4DMTebyusUk9PVA (My Drive root)
• • • • • Write with explicit parentId: FAILS — tested on daisy folder, inbox subfolder, and a brand new test folder
• • • • • • Error message: "User cannot add children to the specified folder"
• • • • • • • OAuth revoke + reconnect: did not fix
• • • • • • • • App update: did not fix
• • • • • • • • • Account: Pro plan, claude.ai web
• • • • • • • • • • Platform: macOS
• • • • • • • • • • Closest existing issues: Claude.ai Google Drive/Gmail/Calendar MCP integrations lack write operations (move, rename, delete/trash) #51040 (feature request framing, different issue), [BUG] Google Drive connector shows connected but tools not exposed in Cowork #30457 (Cowork-specific, different issue)

[matheushenriquefs]

Such a bummer that this stopped working :/
I have a workflow at my job that relies on this behavior

[Nicci-Mack]

Reproducing on a separate organization. Supports likely an Anthropic-side regression, not a per-user or per-permission issue. Adding data points and one observation that broadens the symptom set.

Reproduction context

• Connector: Google Drive via Cowork (claude.ai web → Settings → Connections)
• Error string: User cannot add children to the specified folder — verbatim match
• First reproduction: 2026-05-04, continuously through 2026-05-08
• 6+ users on the same org, separate OAuth sessions, separate target folders, identical failure

Additional data point — Shared Drive case

Our primary target is a Google Shared Drive (not My Drive). Every create_file call against any folder in the Shared Drive: canonical folder, subfolders, brand-new test folders fails with the same error string. Folder creation also fails the same way.

Combined with OP's finding that My Drive writes with an explicit parentId also fail (while writes with no parentId succeed and land at Drive root), this rules out a Shared-Drive-only root cause. The regression appears to affect any create_file call with an explicit parentId, regardless of Drive type.

Same-session diagnostic: reads work, writes fail

In a single Cowork session against the same target folder:

• get_file_permissions → succeeds. Returns my role as organizer (Manager) and the organization domain as fileOrganizer (Content Manager). Both roles grant canAddChildren: true per the Drive API.
• create_file with that folder as parentId → fails with the error above.

Auth, scope, role, and Drive-side permissions are confirmed correct via the connector itself. The bug is in the create_file write code path, specifically when parentId is set.

Mitigations tried, none fix it

• Disconnect + reconnect connector (multiple users, multiple attempts, over multiple days)
• OAuth revoke at myaccount.google.com/connections + full reauth
• Connector tool refresh
• Claude desktop app update

Hypothesis

Regression in the create_file code path's handling of the parents field on the Drive API request

A secondary suspicion was missing supportsAllDrives=true for Shared Drive writes (a documented Drive API requirement (https://groups.google.com/g/google-apps-script-community/c/bH-kn9UW_cg)). OP's My Drive failure rules it out as sole cause, but it may still be an additional issue stacked on top for Shared Drive users. Both symptoms could share the same parents field-handling regression.

Operational impact

For users on Shared Drives, the connector is effectively zero-write. Per #51040, create_file is the only write tool exposed — no move_file, rename_file, copy_file, or trash_file exists as a fallback. When create_file is broken on every parented call, the integration becomes effectively read-only for any user with a folder structure they care about.

A separate Anthropic support thread is open with my org as of 2026-05-07 with engineering escalation requested with Fin basically dismissing the issue. Cross-referencing this issue in that thread.

[abnickerson]

My Claude uses the create_file function as part of it's workflows. Can confirm it was working properly on 2026-05-07 at around 1AM Pacific. By the time I returned to work on the project (about 9 hours later), the functionality was busted. No change to project or connector permissions. Tried everything mentioned above (connector disconnect/reconnect, full removal and re-addition of the connector, etc) - nothing worked. Still broken today as of this writing.

[nataliamirapeix-ux]

+1 from another platform/plan combo, broadening the matrix:

• Client: Claude desktop app on Windows 11 (OP is claude.ai web on macOS; @Nicci-Mack is Cowork web; @luff-mitchell on the umbrella Claude.ai Google Drive/Gmail/Calendar MCP integrations lack write operations (move, rename, delete/trash) #51040 is web + Android)
• Plan: Pro, individual account (Nicci-Mack is org/Shared Drive)
• Drive type: My Drive, owned folder (IDEAS SUELTAS nested under PROYECTOS PROPIOS)
• Tested: today 9 May 2026 ~11:13 UTC
• Error: identical — User cannot add children to the specified folder
• Request ID: req_011CarufPd76eiJCKUecjWtV

Combined matrix across reports in this thread + #51040: client (web / desktop / mobile / Cowork), OS (macOS / Windows / Android), plan (Pro individual / Team org), Drive type (My Drive / Shared Drive). All fail identically with an explicit parentId. Strongly supports @Nicci-Mack's read that the regression sits in create_file's handling of the parents field, not in auth/scope/permissions — the matrix is too wide for it to be anything else.

Broader context — including why fixing this in isolation isn't enough without a move_file companion to recover all the docs Claude has had to dump into Drive root in the meantime — in my comment on the umbrella issue #51040.

This issue and #51040 are both labelled invalid — doesn't seem to be related to Claude Code by the autoclassifier. Both are first-party claude.ai connector bugs, not Claude Code CLI bugs. A maintainer reroute to the connector team would help — otherwise these reports keep falling between repos.

[kpujjigit]

+1 - key organization workflows currently disabled due to this regression.

[Nicci-Mack]

Day 7 update (2026-05-10, Sunday): Still reproducing on NPP. Fresh create_file test against the same Shared Drive folder, same OAuth session, returns the verbatim error:

User cannot add children to the specified folder.

No fix has landed. Posting to keep the issue active and to confirm this isn't a transient blip... it's been continuously reproducing for 7 days now, across multiple users, multiple folders, and (per OP's report and ours combined) across both My Drive and Shared Drive setups. /bug

[daisyadmin]

Day 7 update from the OP filer (filed via Cowork on 2026-05-08).

Asking for re-triage. This issue is currently labeled invalid with no engineer comment in the thread. The reproduction matrix the community has built over the last seven days argues against that label:

• Clients: claude.ai web, Cowork web, Claude desktop (Windows), Claude mobile (Android)
• OS: macOS, Windows, Android
• Plans: Pro individual, Team org
• Drive types: My Drive (owned folders, nested folders, brand-new test folders), Shared Drive (canonical folder, subfolders, brand-new test folders)
• Independent reporters: 5+ across separate OAuth sessions, separate orgs, separate target folders
• Continuous reproduction window: 2026-05-04 → 2026-05-10 (7 days, no transient gaps)
• Failure mode is identical across the matrix: create_file with explicit parentId returns User cannot add children to the specified folder. create_file without parentId succeeds and lands at Drive root. Reads (search_files, read_file_content) work normally in the same session.

That matrix is too wide to be a per-user, per-permission, or per-account-state issue. It is a regression in create_file's handling of the parents field, as @Nicci-Mack and @nataliamirapeix-ux have already diagnosed in detail above.

On my side, additional frequency data: 5+ create_file failures within a single 6-hour session on 2026-05-08, plus 4 more across the preceding 4 days. Same parentId successfully written to earlier in the session, then permission-denied later — auth state appears to degrade mid-session. Drive web UI confirms ownership of the folders throughout; the permission claim is false.

Operational impact for downstream automation: the parents-field path is the only working write surface for any pipeline that needs to file artifacts into a specific folder. Falling back to "no parentId, lands at root" is not a workaround — it pollutes the Drive root, breaks any folder-based routing convention, and (per @nataliamirapeix-ux's note) requires a move_file companion to recover, which the connector also doesn't expose. So in practice this regression has stopped a class of workflows entirely for 7 days.

Requesting:

1. Re-evaluation of the invalid label given the matrix above.
2. Acknowledgment from an engineer that the regression is being investigated.
3. ETA or scope (web connector only? specific commit? rollback possible?) when known.

Happy to provide additional traces, request IDs, or run a specific reproduction if it would help. /bug

[Nicci-Mack]

Bug Report: Cowork Google Drive connector — create_file returns "User cannot add children to the specified folder"

Date observed: 2026-05-05 → 2026-05-11
Connector: Cowork Google Drive (MCP)
Tool: create_file
Severity: High - Blocks file writes to Drive from Anthropic Claude Cowork sessions

Summary:
create_file against the Cowork Google Drive connector is returning the error User cannot add children to the specified folder. across multiple parent folders, including folders where writes had previously succeeded in another active Cowork session. The failure reproduces in a brand new Cowork chat with no prior context, ruling out per-session state as the cause.
Reproduction
Two create_file write tests were executed back-to-back in a fresh Cowork chat
Test 1 — folder previously failing for me
Result: FAILED
Error string (verbatim): User cannot add children to the specified folder.

Test 2 — folder previously succeeding for me (in another session)
Result: FAILED
Error string (verbatim): User cannot add children to the specified folder.

Re-run on 2026-05-11
Both tests were re-executed on May 11, 2026 with identical parameters. Both failed with the identical error string. No change from May 10 or prior.

The error is not session-scoped. A brand new Cowork chat reproduces the same failure, so per-session token / state corruption is unlikely. The same error is reproduced after Drive disconnect/reconnect, reauthentication. Files and folders are able to be created manually in drive - which defeats the purpose of having the drive connector in cowork.

Expected behavior
create_file should succeed for parent folders the authenticated Google user has edit/contributor access to. The user account has owner/editor access to both test folders in Drive directly.

Fin AI chat in Claude dismisses this issue entirely for days now. Need engineer, this is a /bug that is impacting larger teams and cowork functionality/rollout.

[nataliamirapeix-ux]

Day 8 update from me — extending my comment of May 9 with fresh data, not another +1. (Correction to that earlier comment: plan is Max, not Pro — typo on my end.)
Re-ran the test today, 2026-05-11 ~14:26 UTC. Same setup otherwise (claude.ai, Max individual, Windows 11 desktop), this time targeting a different owned folder in My Drive.

create_file with explicit parentId (an owned folder, role: owner): FAILS — User cannot add children to the specified folder. — request_id: req_011CavwHetWSNRA2EGfTfM5W
create_file with no parentId (control): succeeds, lands at My Drive root (0AM969h6XI8LgUk9PVA).
get_file_permissions on the same parent folder in the same session: returns role: owner for my account. The connector's permission claim is verifiably false.

This extends @Nicci-Mack's same-session get_file_permissions → create_file diagnostic from Shared Drive (organizer + fileOrganizer roles) to My Drive with role: owner. Same failure, different Drive type, different role tier. The bug is not auth/scope/role-sensitive — it's the parents field handling in create_file, as already hypothesized in this thread.
Operational impact, concrete case: I run a long-form note-keeping workflow where dossiers are written to a specific folder. For 8 days the workaround has been: write to Drive root with a fixed filename prefix so I can filter and manually drag files into the target folder from any device. It works but it's exactly the failure mode I flagged in #51040 — the connector becomes effectively read-only for any folder-based organization scheme, users become their own move_file, and Drive root accumulates artifacts that don't belong there. Per #51040, no move_file tool exists to recover them.
Still requesting:

Removal of the invalid label and reroute to the connector team.
Engineer acknowledgment in-thread.
Even a "we see this, investigating" comment would be enough to stop the daily +1 cycle.

Happy to provide additional request IDs or run further reproductions on request. /bug

[Nicci-Mack]

Filed a new issue with fresh evidence: #58057
Highlights:

Different account, different plan than @daisyadmin's original report: same exact error string User cannot add children to the specified folder.

Fresh Cowork chat reproduction on 2026-05-10 and again on 2026-05-11 rules out per-session token corruption.
Two parent folders tested, including one where writes were succeeding for the same Google identity from a parallel Code/Cowork session within the same calendar day rules out folder-level Drive ACL as the cause.
Connector-side regression hypothesis: OAuth scope drift (possibly to drive.file), or a missing supportsAllDrives flag on files.create, coinciding with the May 7 platform incident.

Requesting re-triage of this issue or routing of #58057 to the Cowork / Code / claude.ai Drive connector team. The invalid label here left the bug without an owning team and it's still blocking real workflow work.

cc @daisyadmin in case you want to subscribe to #58057 for updates.

[Nicci-Mack]

Hopefully I am not speaking too soon - but this appears to be resolved as of this morning across my team and I.