[BUG] Claude in Chrome v1.0.74 denies ALL navigation ("permission denied by user") with no prompt after re-pair — stale account-side state What's Wrong?

Open 💬 0 comments Opened Jun 16, 2026 by cookyboy72

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?

[BUG] Claude in Chrome v1.0.74 denies ALL navigation ("permission denied by user") with no prompt after re-pair — stale account-side state
What's Wrong?
After a routine re-pair, the Claude in Chrome extension returns permission denied by user instantly on every navigation attempt, on all sites, with no approval prompt shown. It worked normally on 2026-06-12 (drove LinkedIn via the Cowork MCP), then broke after reconnecting. Appears to be a stuck server-side bridge/permission state (cf. #27055, #32011, #34058, #25878) — no client-side reset clears it.
Environment
OS: macOS · Claude desktop app (Cowork), latest · Claude in Chrome (Beta) v1.0.74, extension ID fcoeoabgfenejglbffodgkkbkcdhcgfn · Plan: Max
Steps to Reproduce

Pair Claude in Chrome with Cowork (worked 2026-06-12).
Re-pair / reconnect the extension.
Issue any navigate call via the MCP.
Observe: permission denied by user instantly, every site, no prompt.

What I ruled out (no effect): disable/re-enable extension, full Chrome restart, full desktop-app restart, re-pair, site access "On all sites", allow in incognito, "Ask before acting" vs "Act without asking".
Is this a regression? Yes — last working 2026-06-12 (v1.0.74 worked that day; broke after a reconnect).
Additional Information: Request: reset the server-side bridge/permission state for this account + extension ID, or expose a client-side force-fresh-bridge option. Intercom support conversation ID: 215474718206099.

What Should Happen?

The extension should honor its permission grant and allow navigation. In "Ask before acting" mode it should show an approval prompt; with site access set to "On all sites" it should act without denying. Instead every navigation is denied instantly with "permission denied by user" and no prompt, on all sites. Expected: navigation and actions work as they did on 2026-06-12.

Error Messages/Logs

permission denied by user
(returned instantly on every navigate call, on all sites, with no approval prompt shown)

Steps to Reproduce

Pair Claude in Chrome with the Claude desktop app (Cowork). Confirmed working 2026-06-12 (drove LinkedIn via the MCP).
Re-pair / reconnect the extension.
Issue any navigate call via the Claude-in-Chrome MCP.
Observe: "permission denied by user" returns instantly, on every site, with no approval prompt.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.0.74 (Claude in Chrome — worked 2026-06-12, broke after a reconnect)

Claude Code Version

Claude desktop app (Cowork), latest — Claude in Chrome extension v1.0.74

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This is the Claude desktop app (Cowork) using the Claude in Chrome MCP, not the Claude Code CLI — the version fields above reflect that. The failure is a stuck server-side bridge/permission state: every navigate call returns "permission denied by user" instantly on all sites with no approval prompt, persisting across disable/re-enable, full Chrome restart, full desktop-app restart, and re-pair. Worked normally 2026-06-12. Same family as #44541 (closed as duplicate), #27055, #32011, #34058, #25878. Request: reset the bridge/permission state for this account + extension ID (fcoeoabgfenejglbffodgkkbkcdhcgfn), or expose a client-side way to force a fresh bridge UUID. Cross-ref Intercom support conversation ID 215474718206099.

View original on GitHub ↗