Claude in Chrome: host-permission denial is reported as a 45s document_idle timeout, and left_click falsely reports success on non-permitted origins

Summary

On this machine every Claude-in-Chrome tool that injects into the page fails,
on every page including example.com, while javascript_tool proves the
page is idle. Two separate defects are visible:

1. executeScript never satisfies document_idle, so all read/screenshot tools time out.
2. computer left_click returns success while delivering no event to the page.

(2) is the serious one: it is a silent false success, so an agent reports work
it did not do.

Environment

| | |
|---|---|
| Claude Code | 2.1.281 |
| Claude Chrome extension | 1.0.94 |
| Chrome | 153.0.8010.53 |
| macOS | 26.6.2 (25G83), Darwin 25.6.0 |
| Date | 2026-09-24 |

Reproduction

Fresh tab group, navigate to https://example.com (1 KB, static, no scripts).

Step 1 — prove the page is idle, via javascript_tool:

({url: location.href, readyState: document.readyState, h1: document.querySelector('h1')?.textContent})

{ "url": "https://example.com/", "readyState": "complete", "h1": "Example Domain" }

Returns instantly, every time.

Step 2 — same tabId, same moment:

| Tool | Result |
|---|---|
| navigate | works |
| javascript_tool | works, instant, correct content |
| get_page_text | Page still loading (executeScript waited 45000ms for document_idle) |
| read_page | same 45000ms document_idle failure |
| find | same 45000ms document_idle failure |
| computer screenshot | Script injection timed out after 5000ms |

The page's readyState is complete, so "Page still loading" is false. The
two injection paths disagree about the same tab at the same instant.

Step 3 — clicks silently no-op:

const a = document.querySelector('a'); const r = a.getBoundingClientRect();
window.__clicks = 0;
a.addEventListener('click', e => { e.preventDefault(); window.__clicks++; });
({x: Math.round(r.x + r.width/2), y: Math.round(r.y + r.height/2)})   // -> {x:215, y:280}

Then computer left_click at (215, 280):

Clicked at (215, 280)

Then re-read the counter:

{ "clicks": 0, "url": "https://example.com/", "listenerStillAttached": true }

The tool reported a successful click. The page received nothing. The
listener survived (so the same JS world persisted across the call), and the URL
never changed.

Ruled out

• Page complexity / slow SPA — example.com is static, and readyState is complete.
• Stale browser process — full quit of Chrome and Claude Code; Chrome's

process start time verified as after the restart. A staged Chrome update had
been pending and has since been applied (153.0.8010.53).

• Stale tab or tab group — fails on a newly created group and fresh tab.
• A single wedged browser — /chrome → Browser 2, with all other

claude --chrome sessions exited: identical failures.

• Competing sessions — only one Claude Code session attached.

Related

• #94757 — identical signature across all pages, macOS, reported 2026-09-16,

described as a regression from the previous day. Also reports javascript_tool
and navigate surviving while left_click/key report success without
delivering events. Open, no maintainer response.

• #78383 — same timeouts on a static page; that reporter found the extension's

"Your approved sites" list read "No sites have been approved yet" despite Site
access being configured, and a full reinstall did not fix it. Suggests the
injection failure may be a host-permission grant that never registers.

Impact

Every documented browser-automation capability except navigate and
javascript_tool is unusable. Because left_click fails silently rather than
erroring, any multi-step automation built on it produces confident, wrong
progress reports — which is worse than an outright failure.

Question for maintainers

Is this a regression in extension 1.0.94 or in Chrome 153, and is there a way to
inspect or reset the extension's host-permission grants (the #78383 symptom)
short of a reinstall, which #78383 reports as ineffective?