Troubleshooting

Gmail Connected, But Agent Can’t Send Attachments?

A deterministic fix path for attachment send failures without falling into reconnect loops.

Common pattern: plain text emails send fine, but the moment you include a file, the send fails or silently drops.

Reality check: this is usually a file/type/size/path problem, not a broken Gmail connector.

Fast path (5 steps)

1) Prove plain-text send still works

Send one tiny no-attachment canary first. If this fails too, fix base Gmail sending before attachment tests.

2) Lock the exact file identity

Before sending, require these fields from the agent: absolute file path, file name, extension, and size.

3) Test one small, common file type

Use one file under 1MB (like .txt or .pdf) to isolate complexity.

4) Capture send proof

Return sender address, recipient, attachment name, size, send status, timestamp, and exact raw error text if any.

5) Change one variable per retry

If it fails, change only one thing: file type, file size, or file path. No multi-variable retries.

Copy/paste recovery prompt

My Gmail connector can send text emails, but attachment sends fail. Do this exactly: 1) Confirm plain-text send works with one canary email. 2) Use ONE attachment under 1MB from this exact path: /absolute/path/to/file 3) Return only: file name, extension, size, absolute path, sender, recipient, send status, timestamp, message ID, and exact raw error text if any. 4) Do not reconnect Gmail unless there is an explicit auth error. 5) If send fails, suggest exactly one next test variable.

High-friction causes

Wrong file path: agent references a file outside its workspace or stale session context.
Unsupported/blocked type: executable or risky extensions can be blocked by provider policy.
Oversized file: attachment exceeds practical or provider limits.
File changed mid-send: temp files, cloud-sync files, or incomplete writes cause intermittent failures.

Advanced edge cases

Unicode/special-character filename issues: rename test file to simple ASCII and retry once.
Directory permissions mismatch: file exists but process can’t read it.
Workspace mismatch: attachment exists in dashboard session but not in current channel/session.
Attachment policy/security filters: send succeeds locally but recipient system strips or quarantines file.

New high-friction cases

Google Drive link vs real attachment: agent included a Drive URL in body text, but no file was attached to the email payload.
Blocked archive/macros: .zip, macro-enabled Office files, or password-protected archives may be blocked by sender or recipient policy.
Alias mismatch confusion: message sends from a different alias/mailbox than expected, then recipient filtering rules hide it.
DLP/compliance hold: send appears successful, but attachment is held, stripped, or delayed by Workspace/admin controls.

Proof rule: require the agent to return both message ID and the exact attachment filename list. If the list is empty, it was not an attachment send.

Loop-break rule: after two one-variable tests with full proof output, stop reconnecting and escalate with evidence.

Escalation packet (copy exactly)

- Sender mailbox + alias - Recipient mailbox/domain - Attachment file name + extension + size - Absolute file path used - Send timestamp + timezone - Message ID (if available) - Exact raw error text - Surface used (dashboard / DM / server / thread) - Result of plain-text canary send

Bottom line: prove file identity + run one small canary attachment + collect exact error text. Most failures are path/type/size issues, not connector auth.