Claude Google Drive Connector Stuck in Re-Auth Loop

The Google Drive connector in Claude keeps asking you to reauthorize after every query — usually a cookie scope, OAuth refresh, or workspace policy issue. Here is the diagnostic path.

You connect Google Drive to Claude. Claude reads one file. You ask a second question, Claude says “I need permission to access Google Drive” and pops the OAuth flow again. You click through. Same thing on the next question. Sometimes it works for ten minutes, then the prompt comes back. The connector status page says “Connected” the whole time, which is the most frustrating part. This is not Claude losing your tokens — it is the OAuth refresh token failing to refresh, or a workspace admin policy invalidating the grant on every API call, or third-party cookies being blocked by your browser, or the access token’s scope mismatching what Claude is requesting at runtime.

Common causes

Ordered by what we see most often in the wild.

1. Third-party cookies disabled in the browser

Claude’s connector flow loads a Google OAuth iframe. If your browser blocks third-party cookies (Safari default, Chrome with strict tracking prevention, Firefox enhanced tracking), the OAuth session cookie cannot persist, so every API call sees “no session” and triggers re-auth.

How to spot it: Open the same flow in a fresh Chrome window with chrome://settings/cookies set to “Allow all cookies” — if the loop disappears, this was it.

Many Google Workspace admins enforce a policy that revokes third-party app tokens nightly or after a fixed idle period. Claude reads this as “token expired” and asks again. The user-side experience: works in the morning, breaks in the afternoon.

How to spot it: Visit myaccount.google.com/security → “Third-party apps with account access” → check the “Last access” timestamp on Claude. If the timestamp is newer than your re-auth click but the loop persists, admin policy is revoking immediately after grant.

If the original OAuth grant did not request offline access, Claude only got an access token, not a refresh token. Access tokens expire in 1 hour. After expiry, Claude has nothing to refresh with, so it prompts for full re-auth.

How to spot it: Loop kicks in roughly 60 minutes after each grant, almost on the dot.

4. Scope mismatch between grant and runtime call

Claude originally requested drive.readonly scope. You later ask it to summarize a doc that requires drive.metadata.readonly too, or to access a shared drive that requires drive.full. The API returns 403, Claude interprets the 403 as auth failure, prompts re-auth.

How to spot it: Loop is intermittent — works on personal-drive files, breaks on shared-drive or admin-restricted files.

5. Multiple Google accounts logged into the browser

Your browser has two Google accounts signed in. Claude’s iframe defaults to “Account A”. The file you are asking about lives in Account B. The API returns “file not found” or “no permission”, Claude treats it as auth failure and re-asks.

How to spot it: Loop happens on specific files, not all files. The “wrong” files are usually in your secondary account.

6. Connector cache corrupted on Claude’s side

Rarer but real. A stale connector record on Claude’s backend points at a revoked token. The Drive page shows “Connected”, but every call fails. The fix is a full disconnect-reconnect; partial reconnects do not clear the bad record.

How to spot it: Loop persists even in a fresh incognito session with all cookies allowed and only one Google account.

Before you start

  • Note exactly how long after a successful grant the loop returns. Sub-1-minute, ~60-minute, and “next day” all point at different causes.
  • Check if you are on a personal Google account or a Workspace account — Workspace introduces admin policy as a variable.
  • List the specific file(s) that trigger the loop — file-specific vs all-files is a key signal.
  • If you have a Workspace admin, confirm whether your org has a “third-party token policy” configured.

Information to collect

  • The exact Claude error / prompt text shown when re-auth is requested.
  • Time between successful grant and loop reappearing.
  • Browser, browser version, and cookie / tracking prevention setting.
  • Number of Google accounts signed into the browser session.
  • Whether the file is in your personal Drive, a shared drive, or owned by another account.
  • A screenshot of myaccount.google.com/security → third-party apps → Claude entry.

Step-by-step fix

Ordered by ROI. Cheapest checks first.

Step 1: Test in a clean Chrome profile

Most reliable diagnostic:

1. Create a fresh Chrome profile (Settings → "Add Person").
2. Sign in to ONLY the Google account that owns the files.
3. Allow all cookies in this profile.
4. Sign in to Claude and redo the connector setup.
5. Run the same query that loops.

If the loop is gone, the original profile had a cookie / multi-account / extension issue.

Step 2: Revoke and reconnect from scratch

Half-reconnects do not work. Full reset:

1. Visit myaccount.google.com/permissions
2. Find Claude (or "Anthropic"), click it, click "Remove Access".
3. In Claude → Settings → Connectors → Google Drive → Disconnect.
4. Close all Claude tabs, hard refresh (Cmd+Shift+R / Ctrl+Shift+R).
5. Reconnect Google Drive in Claude. On the consent screen, confirm
   you see "See, edit, create and delete all your Google Drive files"
   or the equivalent broad scope.

The broad scope is needed for Claude to handle shared drives and metadata.

On the Google OAuth consent screen, look for “Allow Claude to access your account when you are not present”. If that line is missing, the integration did not request access_type=offline. There is no user-side toggle — you need to update Claude or contact support. As a workaround, manually re-grant access by visiting Claude’s connector page; this re-runs the OAuth dance and sometimes re-acquires offline access.

Step 4: For Workspace users, check admin policy

If you are on a Workspace plan:

Admin Console → Security → API Controls → 
  Manage Third-Party App Access → search "Claude" / "Anthropic"

If Claude is in “Limited” or “Restricted” mode, ask your admin to mark it as “Trusted”. Otherwise the workspace will revoke its tokens on a policy schedule and the loop is unavoidable.

Step 5: Disable browser extensions one at a time

Privacy / cookie-blocking extensions are a common cause. Test:

1. Open Claude in an Incognito / Private window with no extensions.
2. Run the same connector query.
3. If the loop is gone, re-enable extensions one at a time and retest.

The usual suspects: uBlock Origin (aggressive mode), Privacy Badger, Ghostery, 1Blocker (Safari).

Step 6: If multi-account, force the right account

Append authuser=<email> to the Drive URL when sharing files with Claude, or sign out of all secondary accounts before connecting. Claude does not have a per-call account picker yet, so the connector is locked to whichever account was active at grant time.

Verify

  • Run 5 consecutive Drive queries in Claude across at least 10 minutes. None should trigger re-auth.
  • Check myaccount.google.com/security — the “Last access” timestamp on Claude should advance with each query without you re-granting.
  • For Workspace users: leave the session idle for the typical policy refresh window (often overnight) and confirm next-day access still works.

Long-term prevention

  • Use a dedicated Chrome profile for Claude + Google Drive work. No personal-browsing extensions, only one Google account.
  • For Workspace users, get Claude on the “Trusted” app list once and your loops vanish for good.
  • Track the exact scope you grant. When the connector asks for a wider scope later, accept it — partial scopes cause silent 403s that look like auth failures.
  • Avoid switching browsers / devices mid-session. Each new device triggers a fresh consent that can hit different policies.
  • If you use a connector heavily, keep a note of the grant date — workspace admins sometimes set 90-day mandatory re-consent.

Common pitfalls

  • “Disconnecting” the connector inside Claude without also revoking at myaccount.google.com/permissions — the stale grant persists and the loop returns.
  • Granting only drive.file scope (per-file picker) and then expecting Claude to summarize files it has not seen yet — every new file triggers re-auth by design with this scope.
  • Connecting from one device, expecting the grant to cover all devices — Workspace policies often bind grants to device fingerprints.
  • Assuming “Connected” on the Claude connector page means tokens are valid. It only means a record exists; refresh failures show up only on use.
  • Pasting Google Drive links into a free-tier Claude account that does not yet have Drive connector unlocked — looks like a re-auth loop, is actually a feature gate.

FAQ

Q: I reauthorized 10 times in an hour. Is this rate-limiting me?

Possibly. Google’s OAuth flow has anti-abuse heuristics. After ~10 grants in 60 minutes you may get a temporary lockout — Claude will then show a generic “permission denied” instead of the OAuth flow. Wait 30-60 minutes and try the full clean-profile fix.

Q: Why does it work for some files but not others?

Almost always a scope or account issue. Files in shared drives, files owned by a different account, or files restricted by org-level DLP all require permissions beyond what was granted. See also Claude connector says no permission.

Q: Does this affect the Claude desktop app or only web?

Both, but for different reasons. Web is mainly cookies / extensions / browser policy. Desktop is mainly OS-level keychain (the OAuth refresh token gets evicted when the OS rotates the keychain on a security update).

Q: Will switching to a personal Gmail instead of Workspace fix it?

Yes for the admin-policy class of causes (cause #2). No for cookies, scope, or refresh-token issues. Try the clean-profile test first to confirm where the bug actually lives.

Tags: #Troubleshooting #Claude #google-drive #connector #OAuth