[BUG] Claude in Chrome: every Google site redirects to "Verify it's you" — Chrome DBSC refuses cookie refresh on extension-initiated navigation; passkey prompt never renders in background tab

Summary

Since roughly 2026-08-30, every Google property (studio.youtube.com, mail.google.com, console.cloud.google.com) opened through Claude in Chrome's navigate tool in an otherwise signed-in Chrome profile redirects to accounts.google.com/v3/signin/confirmidentifier ("Verify it's you — Google needs to verify it's you. Please sign in again to continue to YouTube/Gmail"). Clicking Next lands on /v3/signin/challenge/pk (passkey), and the WebAuthn/Touch ID sheet never appears because the tab is in a background tab group.

The user's own tabs in the same profile stay signed in with no challenge. Non-Google sites (Kijiji, Facebook Marketplace, Amazon) load fully signed-in from the same Claude-driven tab.

Confirmed root cause: Chrome Device Bound Session Credentials (DBSC). Disabling chrome://flags/#enable-bound-session-credentials and restarting Chrome makes Studio/Gmail load immediately in Claude's tab with no challenge.

Why it happens

• DBSC binds Google's short-lived __Secure-*PSIDTS cookies to a device key and must refresh them before a request.
• net/device_bound_sessions/session.cc — Session::AllowedToInitiateRefresh(initiator) only permits the refresh when the initiator is absent (browser-initiated), same-site, or in the site's allowed_refresh_initiators. Otherwise it records kInScopeRefreshNotAllowed and sends the request with the stale bound cookie.
• chrome/browser/extensions/api/tabs/tabs_api.cc — chrome.tabs.update / tabs.create set is_renderer_initiated = true with initiator_origin = <extension origin>.
• The extension (v1.0.91) navigates via chrome.tabs.create / chrome.tabs.update, so every Claude navigation carries initiator chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn, the refresh is refused, and Google sees an expired session → step-up sign-in.
• The user's omnibox / link navigations have no extension initiator, so they refresh normally.

Timing matches: DBSC shipped on macOS from Chrome 147 and is Finch-gated; this profile's Default/Device Bound Sessions DB was created 2026-08-30, which is when the symptom started.

Secondary issue: even after the challenge, the passkey prompt never renders. content/browser/webauth/authenticator_common_impl.cc — IsFocused() requires the WebContents to be the focused window's active tab; the WebAuthn UI is tab-modal and only paints over the active tab. Claude's tabs are created in a background tab group (visibilityState: hidden, cf. #78533), so the request hangs silently.

Environment

• macOS 26 (Darwin 25.6.0), Google Chrome 152.0.7977.76
• Claude in Chrome extension 1.0.91
• Claude Code 2.1.263, mcp__claude-in-chrome__navigate / tabs_create_mcp
• Google account with passkey enabled; DBSC enrolled (profile has Device Bound Sessions DB)

Repro

1. Chrome with DBSC enabled (default on current macOS Chrome), signed in to a Google account in the profile; confirm https://studio.youtube.com loads in a normal tab.
2. From Claude Code, tabs_context_mcp {createIfEmpty:true} then navigate the new tab to https://studio.youtube.com/ (or https://mail.google.com/).
3. Observe redirect to accounts.google.com/v3/signin/confirmidentifier → "Verify it's you".
4. DevTools → Network → "Device bound sessions" column on the request shows InScopeRefreshNotAllowed.
5. Set chrome://flags/#enable-bound-session-credentials to Disabled, restart Chrome, repeat step 2 → page loads signed-in.

Suggested fixes

• Navigate via a browser-initiated path (e.g. chrome.tabs.create without an initiator-bearing update, or open through the omnibox / chrome.tabs.create({url}) semantics that DBSC treats as browser-initiated), or perform the initial navigation with CDP Page.navigate after the tab exists — whichever path Chromium classifies as browser-initiated.
• Alternatively pursue listing the extension origin in Google's allowed_refresh_initiators.
• For the passkey problem: when a page requests WebAuthn, activate the tab (chrome.tabs.update({active:true}), focus the window) so the sheet can render, or surface a "bring tab to front" prompt to the user.
• Document the DBSC interaction and the flag workaround in the Claude in Chrome docs until fixed.

Workarounds that do NOT help

• A separate Chrome profile (DBSC is per-profile, same code path).
• --silent-debugger-extension-api (only hides the debugger banner).