You connect Google Drive to Claude. Claude reads one file. You ask a second question and Claude says it needs permission to access Google Drive, then re-opens the OAuth flow. You click through. Same thing on the next question. Sometimes it works for ten minutes, then the prompt comes back. Often the prompt reads “Please try again. You may need to reconnect with your Google Drive account.” The connector page says “Connected” the whole time, which is the most frustrating part.
Fastest fix that resolves most cases: open Claude in a fresh Chrome profile signed into only the Google account that owns the files, set that profile to allow all cookies, then fully revoke and re-add the connector (revoke at myaccount.google.com/connections, not just inside Claude). That clears the two most common culprits at once — blocked third-party cookies and a stale grant. The rest of this page is for when that does not stick.
“Connected” is not the same as “the token still works.” It only means a connector record exists. A re-auth loop means one of these is failing: the OAuth refresh token can’t refresh, a Workspace admin reauthentication policy invalidates the grant on a timer, your browser is blocking the OAuth session cookie, or the granted scope doesn’t match what Claude needs at runtime.
Where the connector lives (June 2026)
Menu labels moved in early 2026, so confirm you are looking in the right place:
- Manage connectors: in claude.ai, Customize → Connectors (direct URL
claude.ai/customize/connectors). The desktop app surfaces the same list under Customize → Connectors. - Toggle a connector for one chat: click the plus (
+) in the message box, hover Connectors, toggle Google Drive on/off. - Disconnect inside Claude: Customize → Connectors → open the Google connector → Disconnect → confirm Disconnect again.
- Revoke the Google grant:
myaccount.google.com/connections→ search for the Claude entry → Delete all connections. (The oldermyaccount.google.com/permissionsURL still redirects here.) - Workspace admins: admin.google.com → Security → Access and data control → API controls → Manage third-party app access.
Google Drive, Gmail, and Calendar connectors are available to all Claude plans, including Free (Google rolled the Workspace connectors out to all users in February 2026). The Drive connector reads Google Docs, Sheets, Slides, PDFs, images, and Microsoft Office files; images embedded inside a document are not processed.
Which bucket are you in?
The single best signal is how long after a successful grant the loop returns. Time it once, then match the row:
| Loop returns after… | Most likely cause | Jump to |
|---|---|---|
| Every single query (seconds) | Third-party cookies blocked, or backend connector record is stale | Step 1, Step 2 |
| Only on specific files | Scope too narrow, or wrong Google account | Step 6, cause #4/#5 |
| ~60 minutes, almost on the dot | No refresh token issued (access_type=offline missing) | Step 3 |
| Works AM, breaks PM / next day | Workspace admin token policy revoking the grant | Step 4 |
| Even in clean incognito, one account | Corrupted connector record on Claude’s side | Step 2 |
Common causes
Ordered by what shows up most often.
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’s default, Chrome with strict tracking prevention, Firefox enhanced tracking), the OAuth session cookie can’t 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.
2. Workspace admin re-authentication policy on a timer
Google Workspace admins can set a Google Cloud session control with “Require reauthentication” turned on. The reauthentication frequency is admin-chosen, from a minimum of 1 hour to a maximum of 24 hours (as of June 2026). When that window closes, Google forces re-auth for the OAuth client, Claude reads that as “token expired,” and asks again. Typical user experience: works in the morning, breaks in the afternoon, or breaks the next day.
Note the nuance: a plain Google web-session-length policy usually does not invalidate a third-party app’s refresh token by itself — the timer that bites the Drive connector is specifically the Require reauthentication control on the OAuth client, and the fix is the admin’s “Exempt trusted apps” checkbox (covered in Step 4).
How to spot it: open myaccount.google.com/connections, click the Claude entry, and check whether it keeps reappearing after you remove it, or check myaccount.google.com/security for the recent-activity timestamp. If the grant timestamp is newer than your last re-auth click but the loop persists, an admin timer is forcing re-auth right after each grant. The tell is that the loop returns on a near-exact clock interval (every 1, 4, 8, or 24 hours).
3. Refresh token never issued (consent missing access_type=offline)
If the original OAuth grant didn’t request offline access, Claude only received an access token, not a refresh token. Google access tokens expire after 1 hour (3,600 seconds) by default. After that, Claude has nothing to refresh with, so it prompts for a full re-auth.
How to spot it: the loop kicks in roughly 60 minutes after each grant, almost on the dot.
4. Scope mismatch between grant and runtime call
Claude originally requested a narrow scope such as drive.readonly or per-file drive.file. You later ask it to summarize a doc that also needs drive.metadata.readonly, or to reach a shared drive that needs broader access. The API returns 403, Claude interprets the 403 as an auth failure and prompts re-auth.
How to spot it: the 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,” but the file you’re asking about lives in Account B. The API returns “file not found” or “no permission,” and Claude treats it as an auth failure and re-asks.
How to spot it: the loop happens on specific files, not all files; the “wrong” files are usually in your secondary account.
6. Connector record 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-and-reconnect; partial reconnects don’t clear the bad record.
How to spot it: the loop persists even in a fresh incognito session with all cookies allowed and only one Google account.
Before you start: collect this
- The exact Claude prompt text shown when re-auth is requested.
- Time between a successful grant and the loop reappearing (sub-minute / ~60 min / next-day).
- 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.
- Personal Gmail vs Workspace account — Workspace adds admin policy as a variable.
- For Workspace: whether your org has a third-party-token or session-length policy configured.
Step-by-step fix
Ordered by ROI — cheapest checks first.
Step 1: Test in a clean Chrome profile
This is the most reliable single diagnostic.
1. Create a fresh Chrome profile (Settings -> "Add Person" / profile picker).
2. Sign in to ONLY the Google account that owns the files.
3. Allow all cookies in this profile (chrome://settings/cookies -> "Allow all cookies").
4. Sign in to Claude and redo the connector setup (Customize -> Connectors).
5. Run the same query that loops.If the loop is gone, your original profile had a cookie, multi-account, or extension problem — keep using this clean profile, or fix the original with Steps 5/6.
Step 2: Revoke and reconnect from scratch
Half-reconnects don’t work. Do a full reset:
1. Visit myaccount.google.com/connections
2. Click the Claude (or "Anthropic") entry -> "Delete all connections".
3. In Claude -> Customize -> Connectors -> open Google Drive -> Disconnect (confirm Disconnect again).
4. Close all Claude tabs and hard refresh (Cmd+Shift+R / Ctrl+Shift+R).
5. Reconnect Google Drive in Claude. On the consent screen, confirm you see the
broad Drive scope ("See, edit, create and delete all your Google Drive files"
or equivalent), then approve.Revoking on the Google side and inside Claude is what clears the stale record — doing only one side is the single most common reason the loop comes back.
Step 3: Force offline access on the consent screen
On the Google OAuth consent screen, look for a line like “Allow Claude to access your account when you’re not present.” If that line is missing, the integration didn’t request access_type=offline, so you only got a 1-hour access token. There is no user-side toggle for this. The workaround is to fully revoke (Step 2) and re-grant from Claude’s connector page — re-running the OAuth dance from a clean state usually re-acquires offline access. If it never does, this is a Claude-side bug; report it to Anthropic support with your repro timing.
Step 4: Workspace users — fix the admin policy
If you’re on a Team / Enterprise (Workspace) plan, the connector must first be enabled org-wide by an Owner, and Claude must be a trusted app. Have your admin do this in the Google Admin console:
admin.google.com -> Security -> Access and data control -> API controls ->
Manage third-party app access -> Add app -> OAuth App Name
-> search "Claude" -> select it -> set access to "Trusted"Three access levels exist:
| Level | What Claude can reach | Re-auth loop? |
|---|---|---|
| Trusted | All Workspace services, including restricted scopes | No |
| Limited | Unrestricted services only | Yes, on restricted-scope files |
| Blocked | No Google data; refresh tokens are invalidated | Yes, permanently |
If Claude is Limited or Blocked, ask your admin to set it to Trusted. Propagation takes roughly 15 minutes, so wait before retesting.
Then close the timer loophole (cause #2): if the org has a Google Cloud session control with “Require reauthentication” enabled, ask the admin to tick “Exempt trusted apps”. Without that checkbox, even a Trusted Claude keeps looping every time the reauthentication window (1-24 hours) closes.
Step 5: Disable browser extensions one at a time
Privacy and cookie-blocking extensions are a common cause.
1. Open Claude in an Incognito / Private window with extensions disabled.
2. Run the same connector query.
3. If the loop is gone, re-enable extensions one at a time and retest.Usual suspects: uBlock Origin (aggressive mode), Privacy Badger, Ghostery, 1Blocker (Safari).
Step 6: Multi-account — force the right account
Sign out of all secondary Google accounts before connecting, or add authuser=<email> to the Drive URL when you share a file with Claude. The connector binds to whichever account was active at grant time; Claude does not yet expose a per-call account picker.
Desktop app note — and a real account-corruption trap
If you use the Claude desktop app and clicking Connect opens claude.ai’s onboarding/signup page (“How are you planning to use Claude?”) instead of the Google consent screen, stop — do not click through. This is a known macOS desktop bug (Anthropic GitHub issue #51002, still open as of June 2026). If you continue past the “Email verified as [your email]” step and press Create account, the desktop app silently creates a duplicate Claude account under the same email but a different sign-in provider, which can lock you out of your existing paid account on web and desktop.
The safe workaround: do the connect step in your browser at claude.ai first (where the real Google consent screen appears), approve there, then return to the desktop app — the grant syncs across surfaces. If you already triggered the duplicate-account flow, contact Anthropic support to merge/delete the duplicate rather than trying to fix it yourself.
How to confirm it’s fixed
- Run 5 consecutive Drive queries in Claude across at least 10 minutes. None should trigger re-auth.
- Check
myaccount.google.com/security(recent activity) — the Claude access timestamp should advance with each query without you re-granting. - Workspace users: leave the session idle past your org’s policy refresh window (often overnight) and confirm next-day access still works.
Long-term prevention
- Keep a dedicated Chrome profile for Claude + Google Drive: one Google account, no privacy/cookie extensions.
- Workspace users: get Claude onto the Trusted app list once, and have the admin tick “Exempt trusted apps” on any Require-reauthentication policy — that removes the timer loop for good.
- When the connector later asks for a wider scope, accept it. Partial scopes cause silent
403s that look exactly like auth failures. - Avoid switching browsers or devices mid-session; each new device triggers a fresh consent that can hit a different policy.
- If you use the connector heavily, note the grant date — some Workspace admins set 90-day mandatory re-consent.
Common pitfalls
- “Disconnecting” inside Claude without also revoking at
myaccount.google.com/connections— the stale grant persists and the loop returns. - Granting only
drive.filescope (per-file picker) and expecting Claude to summarize files it hasn’t seen — every new file triggers re-auth by design with that scope. - Connecting from one device and expecting the grant to cover all devices — Workspace policies often bind grants per session.
- Assuming “Connected” means the token is valid — it only means a record exists; refresh failures surface only on use.
- Pasting Drive links into a Claude account whose Workspace admin hasn’t enabled the connector org-wide — it looks like a re-auth loop but is actually a policy gate.
FAQ
Q: I reauthorized 10 times in an hour. Is Google rate-limiting me?
Possibly. Google’s OAuth flow has anti-abuse heuristics; after roughly 10 grants in 60 minutes you can hit a temporary lockout, and Claude then shows a generic “permission denied” instead of the OAuth screen. Wait 30–60 minutes, then run the clean-profile fix (Step 1).
Q: Why does it work for some files but not others?
Almost always scope or account. Files in shared drives, files owned by a different account, or files restricted by org DLP need permissions beyond what you granted. See also Claude connector says no permission.
Q: Does this affect the Claude desktop app or only web?
Both, for different reasons. Web is mainly cookies, extensions, and browser policy. Desktop is mainly the OS keychain — the OAuth refresh token can be evicted when the OS rotates the keychain on a security update. There is also a still-open mid-2026 desktop bug (GitHub #51002) where “Connect” routes to the signup page instead of the consent screen and can create a duplicate account; connect in the browser first, and do not click “Create account” in the desktop flow.
Q: Will switching from Workspace to a personal Gmail fix it?
Yes for the admin-policy class of causes (cause #2). No for cookies, scope, or refresh-token issues. Run the clean-profile test first to confirm where the bug actually lives.
Q: Is the connector available on Claude Free?
Yes — Drive, Gmail, and Calendar connectors are available on all plans including Free (rolled out to all users in February 2026). On Team/Enterprise an Owner must enable them org-wide before individuals can authenticate.
Q: The prompt says “Please try again. You may need to reconnect with your Google Drive account.” What does that mean?
That is Claude’s generic re-auth message when a runtime Drive call fails authentication — it does not tell you why. Follow the full revoke-and-reconnect in Step 2 first; if it returns, time the interval and use the “Which bucket are you in?” table to find the real cause. Workspace admins can confirm the app’s access level and reauthentication policy from Google’s app-access control docs.
Related
- Claude connector says no permission
- Claude Chrome connector issue
- Claude GitHub connection failed
- Claude MCP server disconnect
- Claude file upload stuck processing
Tags: #Troubleshooting #Claude #google-drive #connector #OAuth