Troubleshooting

Gmail Connected, But Agent Won’t Send?

A fast, proof-first workflow to fix Gmail connector loops without blind reconnect retries.

Common pattern: Gmail shows as connected, but the agent still says it can’t send, keeps asking to reconnect, or returns vague auth errors.

Reality check: “Connected” alone is not proof. You need one successful canary send in the same surface/session where you plan to work.

Fast path (4 steps)

1) Confirm the exact Google account

Most failures come from connecting one Google account and testing with another expectation. Verify the mailbox address explicitly before testing sends.

2) Complete OAuth in one clean browser pass

Use one browser profile, complete every consent/security screen, then stop reconnecting repeatedly. Partial OAuth completion creates looped failures.

3) Run a tiny canary email

Send a single plain-text message to yourself with a unique subject, for example:

GMAIL_CANARY_{{today}}_{{time}}

Success requires: returned message ID + received message in Inbox or Sent.

4) Only then run production tasks

Do not jump to newsletters or bulk outreach until the canary send is proven in the same chat surface/thread.

Copy/paste recovery prompt

My Gmail connector appears connected, but sending is unreliable. Do this exactly: 1) Confirm which Gmail address is currently authorized. 2) Send ONE plain-text canary email to: MY_EMAIL@example.com 3) Subject: GMAIL_CANARY_TEST 4) Body: "canary" 5) Return only: authorized Gmail address, send status, message ID, and exact error text if it fails. 6) Do not reconnect unless you show a specific auth error first.

High-friction failure patterns

Account mismatch: connected account is different from the mailbox you think is active.
Interrupted OAuth: consent/security screens were partially completed, then user returned to chat too early.
Cross-surface mismatch: connector was linked in one surface/session but tested in another.
Over-broad first task: users test with multi-recipient or formatted campaigns before proving basic send.

Advanced edge cases (when basic checks pass but sends still fail)

Send-as alias not verified: Gmail can be connected, but sending from a custom alias/domain fails until alias verification is complete.
Workspace admin restriction: Google Workspace org policies may block external recipients or restrict app access even after OAuth appears successful.
Daily or anti-abuse cap: canary may pass, then larger sends fail with quota/rate-style errors; capture exact error text and reduce send volume.
Draft-vs-send confusion: task may only create a draft or fail silently after draft creation. Require explicit “sent” proof + message ID.

Loop-break rules

Stop the reconnect spiral: no more than one reconnect attempt per diagnostic cycle. If canary still fails, capture exact error text and escalate with evidence instead of repeating setup.

What to include if you escalate

Authorized Gmail address shown by the agent
Exact canary recipient + timestamp (with timezone)
Surface/context used (dashboard, DM, server channel, thread)
Exact raw error message (no paraphrase)
Whether the canary appeared in Sent/Inbox

Bottom line: prove one canary send first. If canary works, scale. If it fails, escalate with exact evidence once—don’t burn time in reconnect loops.