Claude in Chrome: permission and credential consent prompts render in a window the user cannot see, so they lapse as "Permission denied by user" / transport_error

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Permission-gated browser calls and 1Password credential requests fail because the consent prompt is dispatched to a Chrome window that is not visible to the user. The prompt renders unseen, is never answered, and lapses. One root cause, two symptom classes: Permission denied by user for navigate, and transport_error for request_credentials.

Reproduced identically in a Cowork session and in claude.ai web chat, so this is not surface-specific.

Symptoms

• request_credentials (kind=login) x6 -> alternating transport_error/retryable (x4) and transport_error/decode (x2), non-deterministically across identical calls. list_granted_credentials -> no_grants.
• No 1Password consent prompt ever appeared on screen.
• navigate to a new domain -> Permission denied by user, twice (once implicit-tab, once with an explicit tabId), with no permission prompt visible.

What fixed it

Opening the Claude side panel. This hid the visible Chrome window and revealed a separate "Claude for Chrome" window displaying "Waiting for permission request...". The original tab group had been stranded in a window the user could not see.

With no other changes:

1. tabs_context_mcp returned a new tabGroupId (1973779837 -> 1667763829); the previously-valid tabId was rejected as outside the group.
2. navigate succeeded immediately.
3. request_credentials returned {"status":"approved"} on the first attempt.
4. autofill_credential returned no_match — correct, not a bug: the vault item signs in with Google, so there is no password to fill.

Why the alternating error codes matter

retryable and decode alternating non-deterministically across identical calls fits a consent request that is never answered and times out differently each time. It does not fit two distinct transport faults. Read as transport faults, they send you investigating 1Password — which is healthy throughout, and which is where a lot of existing reports have stalled.

Likely relationship to existing issues

This appears to explain a cluster of reports where users see permission denials with no popup ever appearing, none of which identify a cause: #53630 (closed, attributed to a debugger-attach retry loop), #66307 (closed as duplicate of #53630), #83959, #68892, #82295, #84538. It also plausibly explains the 1Password credential-request failures in #79976.

What Should Happen?

Two acceptable behaviours, in order of preference:

1. request_credentials and any permission-gated browser call should focus or raise the consent window when dispatching the request, so the user can see and answer the prompt.

1. Failing that, they should return an actionable error naming the real condition — for example consent_window_not_active — rather than a generic transport_error or a silent Permission denied by user.

The current errors are actively misleading. Permission denied by user reports a decision the user was never given the opportunity to make, and transport_error points at the transport layer when the transport is fine.

Error Messages/Logs

request_credentials, six consecutive identical calls:
  {"status":"transport_error","reason":"retryable"}   x4
  {"status":"transport_error","reason":"decode"}      x2
list_granted_credentials:
  {"status":"no_grants"}
Also observed on the same path from a Cowork session:
  {"status":"unavailable","reason":"local_browser_unavailable"}

navigate to an unapproved domain (no prompt visible on screen):
  Permission denied by user      (implicit tab)
  Permission denied by user      (explicit tabId)

After opening the Claude side panel, with no other changes:
  tabs_context_mcp -> tabGroupId 1973779837 -> 1667763829 (prior tabId rejected as outside the group)
  navigate         -> success
  request_credentials -> {"status":"approved"}      (first attempt)
  autofill_credential -> {"status":"no_match"}      (correct: item signs in with Google)

Steps to Reproduce

1. macOS with Chrome and the Claude in Chrome extension paired. For the credential half, 1Password desktop app running and unlocked, extension signed in.
2. Start a session — Cowork task or claude.ai web chat — with the Claude side panel not open.
3. Call mcp__claude-in-chrome__navigate to a domain not previously approved.

-> Permission denied by user. No prompt appears anywhere on screen.

1. Call request_credentials with kind=login and a website you have a vault item for. Repeat several times.

-> transport_error, reason alternating between retryable and decode. No 1Password prompt appears.

1. Open the Claude side panel. A separate "Claude for Chrome" window becomes visible, displaying "Waiting for permission request...".
2. Call tabs_context_mcp -> a new tabGroupId is returned and the previously-valid tabId is rejected as outside the group.
3. Repeat steps 3 and 4 -> both now succeed. request_credentials returns approved on the first attempt.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.220 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The version fields above do not fit this bug — it is in the Chrome extension and the desktop/web client, not the CLI. Actual component versions:

• Claude in Chrome extension 1.0.90
• Claude desktop app 1.44121.4 (Electron 42.10.0); also reproduced in claude.ai web chat
• macOS 26.4.1, Apple Silicon
• Chrome 152.0.7977.77
• 1Password desktop app and Chrome extension both current, app running and unlocked throughout

Corroborating tab-group churn

Observed independently in a separate session while investigating this: two consecutive tabs_context_mcp calls returned different group IDs (918760806, then 1253387548), with both returned tabIds rejected as outside the group before a third attempt succeeded. Consistent with tab groups being created against a window that is not the one the user is looking at.

Ruled out

• 1Password health. App running and unlocked, extension signed in, both current. Enabling 1Password's own "SDK" and "MCP client" integration toggles had no effect, as expected — those are 1Password's MCP server, not the browser relay.
• Surface. Reproduced in both Cowork and claude.ai web chat; the fix works on either.
• Browser routing. See below.

Separate issue that cost investigation time

Not the cause here, but worth flagging for anyone triaging this cluster: list_connected_browsers did not reflect a user-assigned browser name and returned generic "Browser 1"/"Browser 2" labels that reassign between physical machines (#78096, #90153). That made a browser-routing hypothesis look plausible for a long time when routing was not the problem at all.