Troubleshooting

Google Drive Connected, But Agent Can’t Upload Files?

A deterministic fix flow for “connected but upload failed” loops: prove account, folder, and permission state before reconnecting again.

Community pattern: Drive shows as connected, reads sometimes work, but uploads fail with vague errors. Most cases are wrong account, wrong target folder/shared-drive permissions, or blocked file type/size assumptions.

Loop-break rule: do not reconnect Drive 5 times in a row. Run one tiny upload canary first, then change only one variable at a time.

What this usually means

OAuth account mismatch: connector linked to Account A while you’re checking files in Account B.
Folder target mismatch: upload went to a different folder/shared drive than expected.
Permission gap: you can view a shared folder but do not have upload/edit rights.
Session/context mismatch: upload attempted in a different surface/thread than where connector is active.

5-minute deterministic recovery flow

1) Lock account + destination first

Tell the agent the exact Google account email and exact destination folder name/path before any upload attempt.

2) Run a tiny canary upload

Upload one small text file (for example canary-drive-upload.txt) and require returned proof: folder name, file name, and created timestamp.

3) Verify from the same account

Open Drive in the same Google account and search exact filename. If missing, check “Recent” and shared-drive destination confusion.

4) If canary fails, check permissions before reconnect

Confirm upload rights in the target folder/shared drive. Read access does not always include create/upload permission.

5) Reconnect once, then retest once

If needed, reconnect Drive in one clean browser flow and immediately rerun the same tiny canary test. Avoid random prompt changes.

Copy/paste recovery prompt

Google Drive is connected, but uploads fail. Do exactly this: 1) Confirm active Google account email you are using for Drive operations. 2) Target this destination folder exactly: [PASTE FOLDER NAME OR PATH]. 3) Upload a tiny file named: canary-drive-upload.txt with content: "drive canary [today's date]". 4) Return proof only: - account email - destination folder/path used - uploaded filename - created timestamp 5) If upload fails, return exact raw error text and one likely cause (no guessing list).

High-friction edge cases

Shared Drive restrictions: some org drives block uploads from external or non-member accounts.
Shortcut confusion: uploading to a shortcut target may place file in an unexpected parent location.
Duplicate filename assumptions: upload succeeds but you are viewing an older same-name file.
Workspace policy blocks: org security policy can allow read while blocking create/upload actions.
File type or size gate: tiny .txt canaries work, but larger files or blocked MIME types fail silently or with generic errors.
Insufficient storage/quota: account or shared drive has no remaining storage, so uploads fail despite valid auth.

If tiny upload works but real file fails

Compare file size: test one medium file (for example 1–5 MB) before large uploads.
Compare file type: try .txt → .csv → your real type (for example .pdf, .docx, .zip).
Keep destination fixed: do not change folder and file type at the same time.
Return exact raw error: require the agent to quote exact provider error text and upload attempt timestamp.

When to escalate

Escalate after one clean canary cycle if upload still fails with the same raw error and account/folder are confirmed.

Support packet: - Goal: "Upload file to Google Drive folder" - Connector status: connected (yes/no) - Active Google account email used - Exact destination folder/path - Canary filename used - Exact raw error text from failed upload - Surface used (dashboard / Discord DM / server thread) - Whether reconnect was attempted once in clean browser flow

Bottom line: treat Drive uploads as a proof-first operation: lock account + folder, run a tiny canary, then scale. This kills most reconnect loops fast.