[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 = `.
- 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).

Start by reproducing the flow with Claude Code's mcp__claude-in-chrome__navigate and tabs_create_mcp using the listed Chrome version and DBSC flag state. Read the cited tabs_api.cc, net/device_bound_sessions/session.cc, and authenticator_common_impl.cc paths; done means Google pages remain signed in during extension navigation and a passkey request is visible rather than hanging in a background tab.

Vom Indexierungsmodell aus dem Issue-Text verfasst.