[BUG] Claude in Chrome 1.0.85: get_page_text, find, browser_batch and ref-targeted computer all fail with generic "failed in the extension" while read_page / javascript_tool / coordinate-targeted computer work on the same tab

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?

On a single tab, within one session, a specific subset of Claude-in-Chrome MCP tools fails 100% of the time with the same generic error: Tool "NAME" failed in the extension (where NAME is the tool called). Sibling tools against the same tabId succeed back-to-back.

Failing (100% reproducible, identical generic error):

| Tool | Error returned |
| --- | --- |
| get_page_text | Tool "get_page_text" failed in the extension |
| find | Tool "find" failed in the extension |
| browser_batch | Tool "browser_batch" failed in the extension |
| computer targeted by ref (e.g. {action:"left_click", ref:"ref_9"}) | Tool "computer" failed in the extension |

Working — same tab, same minute:

• read_page — returns a real accessibility tree with ref_N ids
• javascript_tool — executes and returns page values
• computer targeted by coordinate — screenshot, scroll, wait, zoom
• navigate, resize_window, tabs_context_mcp, tabs_create_mcp, tabs_close_mcp

Key discriminator: computer is not broken as a tool. It fails only when the target is supplied as ref rather than coordinate. So the failure tracks the element-query / ref-resolution path — which is exactly what find and get_page_text also depend on.

This is not a permission denial:

• Extension site access is set to On All Sites (verified in the "This Can Read and Change Site Data" submenu).
• The failures occur on claude.ai itself, where read_page and javascript_tool demonstrably return real DOM in the same session.
• A permission denial would fail uniformly per-origin, not per-tool. This is per-tool.

What Should Happen?

get_page_text, find, browser_batch and ref-targeted computer should work on any tab where read_page and coordinate-targeted computer already work.

Secondary ask, independent of root cause: the bridge should surface the underlying extension error instead of collapsing it into Tool "X" failed in the extension. That string carries no diagnostic signal, and it is why localizing this took roughly 20 tool calls.

Error Messages/Logs

Tool "get_page_text" failed in the extension
Tool "find" failed in the extension
Tool "browser_batch" failed in the extension
Tool "computer" failed in the extension     <- only when targeted by ref, e.g. {action:"left_click", ref:"ref_9"}

No further detail is returned by any of the four. Coordinate-targeted computer calls on the same tabId return normally.

Steps to Reproduce

1. Open Cowork in the Chrome side panel on any https://claude.ai/... tab.
2. Call read_page on that tabId -> succeeds, returns a tree containing ref_1 ... ref_17.
3. Call get_page_text on the same tabId -> Tool "get_page_text" failed in the extension.
4. Call find on the same tabId -> Tool "find" failed in the extension.
5. Call computer {action:"left_click", ref:"ref_9"} -> Tool "computer" failed in the extension.
6. Call computer {action:"screenshot"} on the same tabId -> succeeds immediately after.

Reproduced across page reloads, a freshly created tab via tabs_create_mcp, and two different origins (claude.ai and a *.frame.claudeusercontent.com artifact page).

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude in Chrome extension 1.0.85 (surface: Cowork in Chrome side panel)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• Surface: Cowork in the Chrome side panel
• Chrome 151 / Chromium 151, macOS
• Claude in Chrome extension 1.0.85, extension ID fcoeoabgfenejglbffodgkkbkcdhcgfn
• Site access: On All Sites

Possible cause (speculative, not verified)

Version skew between the MCP tool schemas advertised to the model and the handlers the installed extension build actually implements: the higher-level tools (get_page_text, find, browser_batch, ref targeting) route to handlers that are absent or renamed, and the bridge collapses the miss into a generic failure rather than an unknown-method error. The primitives keep working because their handlers are unchanged. Treat this as a guess — the load-bearing evidence is the pass/fail matrix and the ref-vs-coordinate discriminator above.

Related

Possibly related but distinct: #79897 (browser_batch always fails with "No tab available" while single-action tools work on the same tabId). Different error string, CLI-only surface, and scoped to browser_batch alone. Here the failure spans four tools from the Cowork side panel.

Impact

Artifact content served in a cross-origin *.frame.claudeusercontent.com iframe becomes unreadable as text:

• get_page_text / find would reach child frames via content scripts — both broken.
• read_page and injected JS only see the top document (cross-origin contentDocument is null; fetch() to the frame origin returns "Failed to fetch", no CORS headers).
• Top-level navigation to the frame URL redirects back to the claude.ai/code/frame/... wrapper, so the content can never be made same-origin.

The only remaining workaround is scroll-and-screenshot, which is lossy: tables with wide code cells are clipped by the artifact own overflow and the clipped column is unrecoverable.