[BUG] Claude in Chrome v1.0.74 — MCP bridge navigation and read tools wedge after May 27 update

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?

After the Claude in Chrome extension auto-updated to v1.0.74 on 2026-05-27, the MCP bridge tools that drive multi-step navigation across websites started failing in a consistent, reproducible way. The same workflows ran cleanly seven days earlier (2026-05-20) on the prior extension version, with no script-level or configuration changes in between. This appears to be a regression introduced in the v1.0.74 release.

Symptoms (in descending order of frequency):

1. navigate returns "Navigated to <url>" but tabs_context_mcp immediately afterward shows the tab URL has not changed. Sometimes fires on retry 2 or 3; sometimes never fires.
2. navigate returns a transport-level timeout error ("The navigate tool did not respond in time...") but the action actually fires in Chrome — the page loads visibly. The MCP response leg appears severed even when the Chrome action leg works.
3. tabs_create_mcp and tabs_context_mcp intermittently return "This session's tab group no longer exists" as a false positive. A re-call moments later finds the same tab group ID still present.
4. get_page_text and javascript_tool time out on certain domains (instagram.com specifically) while working reliably on others (google.com, studio.youtube.com).
5. After a small number of failing calls (typically 3-5), the tab group is actually torn down and recovery requires tabs_context_mcp createIfEmpty: true to start over.

Local restart cycles (full Chrome quit, full Cowork/Claude Desktop quit, relaunch both) do NOT clear the symptoms. Chrome 148 point-version churn (.179 → .216) also did not help; symptoms got marginally worse on .216.

What Should Happen?

Navigation, tabs_create_mcp, and read tools (get_page_text, javascript_tool) should succeed within the normal 1-retry budget when driving multi-step browser workflows via the MCP bridge, as they did before the v1.0.74 update.

Error Messages/Logs

Tab <id> no longer exists. Call tabs_context_mcp to get current tabs.

This session's tab group no longer exists (tabs were closed). Call tabs_context_mcp with createIfEmpty: true to create one.

The "navigate" tool did not respond in time. The Chrome extension is connected but the page may be loading, unresponsive, or waiting on a permission prompt in the extension side panel.

No tab group exists for this session. Use createIfEmpty: true to create one.

Steps to Reproduce

1. From a fresh Cowork session on macOS with Claude in Chrome v1.0.74 installed and signed in, call list_connected_browsers, then select_browser, then tabs_context_mcp with createIfEmpty: true.
2. Call tabs_create_mcp to create an empty-URL working tab.
3. Call navigate with the new tabId to any HTTPS URL on a real domain (e.g., https://www.google.com).
4. Observe: the first navigate either reports success with no URL change, or times out at the MCP transport while the page actually loads in Chrome.
5. Retry navigate on the same tabId. Same result, or the tab group is reported as destroyed.
6. Call tabs_context_mcp without createIfEmpty: it returns "No tab group exists for this session" even though the tab was alive moments earlier.
7. Repeat across other domains (studio.youtube.com, instagram.com, tiktok.com, x.com, threads.com). Some domains are more failure-prone than others — instagram.com reliably blocks both get_page_text and javascript_tool calls; others are more variable.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Pre-v1.0.74. Last confirmed clean multi-step run on 2026-05-20. Chrome auto-updates the extension silently, so I don't have a precise prior version number, but v1.0.74 released 2026-05-27 per the Chrome Web Store listing.

Claude Code Version

N/A — this bug is in the Claude in Chrome extension (v1.0.74), not Claude Code CLI. Driven via the MCP bridge from Cowork mode (Claude Desktop).

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

This bug is in the Claude in Chrome extension (v1.0.74), driven via the MCP bridge from Cowork mode (Claude Desktop). Several form fields above are CLI-specific and have been answered with that context in mind.

Environment:

• macOS, Apple Silicon (arm64)
• Chrome 148.0.7778.216 (Official Build)
• Claude in Chrome extension v1.0.74 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
• Extension is enabled, signed in, "On all sites" access granted
• Service worker, offscreen.html, sidepanel.html all loaded

Likely related open issues (similar symptom classes, may share a root cause):

• #29523 — Tab groups don't persist, connection drops during long tasks (service-worker idle timeout)
• #21106 — tabs_context_mcp works but every other tool fails with "No tab available"
• #37538 — tabs_create_mcp creates tabs but URL parameter ignored (matches "navigated but URL didn't change")
• #50157 — v1.0.68 blocked navigation through MCP bridge; v1.0.74 may be a regression of the same class

The v1.0.74 release-date correlation (same calendar day as symptom onset) is what suggests this is a fresh regression rather than one of the above re-surfacing.

What does NOT fix it:

• Quitting Chrome and Claude Desktop fully and relaunching both
• Allowing Chrome to update through a point release (.179 → .216 made it slightly worse)
• Logging out of a secondary paired browser (the lingering pairing record persists in list_connected_browsers but the active calls all route to the local browser anyway)
• Starting a fresh Cowork thread

Severity: blocking for any workflow that needs to drive multi-step browser navigation via the MCP bridge. Single-call usage may still work; multi-step flows do not.

Happy to provide a fuller call trace, screenshots, or repro across additional domains if useful.