computer tool's screenshot/find/read_page/scroll consistently timeout with "document_idle" wait failure across ALL pages

Independent reproduction of this on a second macOS machine today (2026-09-24), filed with full detail as #96797.

Two details from that run that may narrow it down:

1. The document_idle wait is demonstrably false. On the same tab at the same moment, javascript_tool returns document.readyState: "complete" with correct page text, while get_page_text/read_page/find fail with executeScript waited 45000ms for document_idle. The two injection paths disagree about one idle tab — on example.com, 1 KB of static HTML with no scripts.

1. The silent click is measurable. Attaching a click listener via javascript_tool, then computer left_click on its coordinates: the tool returns Clicked at (215, 280) while the in-page counter stays at 0 and location.href is unchanged. The listener survives the call, so the JS world persisted — the event simply never arrived. This confirms the "report success but do NOT deliver events" behaviour in the original report, and it is the part that makes the bug unsafe rather than merely inconvenient: agent automation reports progress it did not make.

Environment: Claude Code 2.1.281, Claude Chrome extension 1.0.94, Chrome 153.0.8010.53, macOS 26.6.2 (25G83). Survives a verified full restart of Chrome and Claude Code, a fresh tab group, and switching to a second browser via /chrome.

Correction from the reporter — this is NOT "all pages", and that changes the bug

Further testing on my side found the variable I had missed, and I want to correct
the record before anyone chases the wrong thing.

The extension here is running with host permissions withheld. From the Chrome
profile's Secure Preferences, extensions.settings.<id>:

withholding_permissions: true
active_permissions.scriptable_host:  ["<all_urls>", ...]
runtime_granted_permissions.scriptable_host: ["*://*.1stdibs.com/*", "*://*.ebay.com/*",
                                              "*://*.etsy.com/*", ...28 origins total]

So there is a finite allowlist of runtime-granted origins. Re-testing against it:

| Origin | In granted list? | screenshot | get_page_text |
|---|---|---|---|
| www.ebay.com (heavy, script-dense SPA) | yes | works, instant | works, instant |
| example.com (1 KB static, no scripts) | no | 5000ms injection timeout | 45000ms document_idle timeout |

The page that fails is the trivial one; the page that works is the heavy one. The
variable is host permission, not page state. My original "fails across all pages,
permissions ruled out" was wrong — I had only ever tested on example.com,
precisely because it was supposed to be the simplest possible control.

The bug that remains is the error reporting, and I'd argue it is worse than the
one I originally filed:

1. A host-permission denial is reported as a page-loading timeout. `Page still

loading (executeScript waited 45000ms for document_idle) is emitted for an
origin the extension may never inject into, on a page whose readyState is
complete`. That message sends you to debug page load, SPA readiness, service
workers and browser restarts — none of which can ever fix it. It cost me most
of a day, and reading the other reports here, I don't think I'm alone.

1. 45 seconds is spent waiting on a condition that cannot be satisfied. The

permission state is known up front; this should fail immediately.

1. **left_click returns success on a non-permitted origin while delivering no

event.** Measured: tool returns Clicked at (215, 280), in-page listener
counter stays 0, location.href unchanged. A silent false success is the
dangerous failure mode for agent automation — it reports work it did not do.

Suggested fix: when the target origin is not in
runtime_granted_permissions, fail fast with something like
No host permission for https://example.com — grant site access via the extension
icon or chrome://extensions, and make left_click return that same error instead
of success.

This may or may not be the same root cause as the original report in this thread —
if others seeing it can check their own runtime_granted_permissions against the
origins they tested, that would separate the two cases quickly.

Second amendment: retracting the Secure Preferences diagnostic (it gives false "permission is fine" readings)

A second machine has now run the same experiment, and it breaks the check I
suggested in my previous comment while leaving the observation intact. Since
that check was the actionable part, please don't use it.

What replicated (MacBook, same day, Chrome 153.0.8010.53, Darwin 25.6.0,
extension 1.0.90):

| Origin | get_page_text / screenshot |
|---|---|
| www.ebay.com — heavy, script-dense | work, instantly |
| example.com — 1 KB static, 129 chars of body text | 45000ms document_idle / 5000ms injection timeout |

Identical to my Mac Studio result. So the per-origin split is real and
reproducible across machines. Page weight and page state do not explain it: the
trivial page is the one that fails.

What did NOT replicate — and this is the important part:

On that machine example.com IS present in Chrome's
runtime_granted_permissions.scriptable_host (both *://example.com/* and
*://*.example.com/*), withholding_permissions: true, 28 granted hosts — and
it still fails, while ebay.com from the same list works.

Therefore Chrome's runtime_granted_permissions does not reflect the
extension's effective per-site permission, and my earlier "check your granted
list" snippet is unsound. On a profile like that one it reports the failing
origin as granted, so anyone following it concludes permission is fine and goes
back to debugging page readiness — exactly the hole I was trying to get people
out of. I'm sorry for publishing it; retracting it here.

Two further corrections to that snippet: it hardcodes the Default profile,
which does not exist on that machine (the extension lives in Profile 1), and
I have not been able to locate an extension-internal permission store that would
explain the disagreement — grepping the extension's Local Extension Settings
LevelDB turns up example.com among many unrelated bundled strings, so it is
not a usable allowlist either.

Status of the mechanism: unknown. Something gates injection per-origin,
Chrome's recorded grants are not it, and I can't currently name what is. What is
solid is the reproducible symptom and its shape.

None of this changes the three defects this issue is actually about, which
hold whatever the gate turns out to be:

1. Whatever the real cause, it is reported as `Page still loading (executeScript

waited 45000ms for document_idle) on a page whose readyState is
complete` — sending everyone to debug page load, SPAs and browser restarts,
none of which can fix it.

1. 45 seconds are spent waiting on a condition that never becomes satisfiable.
2. left_click returns Clicked at (x, y) while delivering no event to the

page (verified with an in-page listener: counter stays 0, location.href
unchanged). Silent false success is the worst failure mode for agent
automation.

The only reliable diagnostic I can now recommend is functional, not
file-based: in one session, try a known-good origin and the suspect origin
back to back. If one works and the other times out, it is not page readiness.

One caution I'd add, credit to the second reporter: javascript_tool succeeding
on a failing page is not evidence about permissions either way — the
extension holds the debugger API permission, so that path may bypass whatever
gates the others entirely. It's a usable escape hatch on an affected origin
(document.body.innerText, querySelectorAll, fetch all work), but "JS reads
the page fine, so the extension must be broken" is an inference that led both of
us astray.

Third and final amendment: mechanism identified — host-permission denial, reported as a page-load timeout

The missing control has now been run on both machines, and it resolves the
contradiction in my previous two comments. Summary: my original diagnosis was
right for ordinary origins, and example.com — the page I used as a control all
day — is a separate anomaly that made it look refuted.

The row neither of us had run: an ordinary ungranted site

Measured on machine A (this one):

| Origin | In granted list? | Result |
|---|---|---|
| www.ebay.com | yes | works, instantly |
| www.therealreal.com | yes | works; left_click delivered (page navigated / → /women) |
| clarity.dexcom.com | yes | works, instantly |
| en.wikipedia.org — ordinary, heavy, real page | no | 45000ms document_idle timeout |
| example.com | no | 45000ms document_idle timeout |

Reported to me by machine B, independently, same day (Chrome 153.0.8010.53,
extension 1.0.90):

| Origin | State | Result |
|---|---|---|
| www.ebay.com | granted | works |
| clarity.dexcom.com | granted mid-session via the extension UI | works immediately, nothing restarted |
| en.wikipedia.org | not granted | fails, 45s timeout |
| example.com | granted at Chrome level (both patterns) and re-added in the extension's own site-access UI | fails |
| www.example.com | granted via *://*.example.com/* | fails |

That gives both controls:

• Positive: granting an origin mid-session makes it work *instantly, with no

restart of anything*.

• Negative: an ordinary, heavy, real page that is simply not granted fails

with the identical 45s document_idle message.

So the gate is host permission, and the error message names page readiness
instead. That is the bug.

Narrowing my previous retraction

My second comment said Chrome's runtime_granted_permissions does not reflect
effective permission. That is still true as a warning — on machine B the file
lists example.com as granted while it fails, so the file is not a safe
diagnostic. But the reason is narrower than I implied: it is example.com's
anomaly, not a general disagreement between the record and the gate. For ordinary
origins the record and the behaviour agree on both machines.

A separate item: example.com fails while granted at both layers

Worth treating as its own defect. It fails with both *://example.com/* and
*://*.example.com/* present, and with the origin added through the extension's
own site-access UI. A plausible explanation is a hardcoded exclusion of the IANA
reserved documentation domain — if that is deliberate, it should say so rather
than time out for 45 seconds, because example.com is the first thing anyone
reaches for as a control, and it turns the canonical smoke test into a permanent
false negative. Both of us lost most of a day to exactly that.

One hypothesis already tested and killed, so nobody repeats it: a matcher
treating *.domain as subdomains-only and excluding the apex would explain every
row, but www.example.com also fails, and curl confirms it returns HTTP 200
directly with zero redirects. It is a genuine subdomain. Not a matcher bug.

Version spread

Machine A: Chrome 153.0.8010.53, extension 1.0.94, Claude Code 2.1.281,
Darwin 25.6.0. Machine B: same Chrome and OS, extension 1.0.90. So the
behaviour spans at least two extension versions — not a single-build regression.

Unchanged — these are the actual fixes

1. A permission denial is reported as `Page still loading (executeScript waited

45000ms for document_idle) on a page whose readyState is complete.
Suggested: No host permission for <origin> — grant site access via the
extension icon or chrome://extensions`.

1. 45 seconds are spent waiting on a condition that can never become satisfiable.

The permission state is known up front; fail fast.

1. left_click returns Clicked at (x, y) on a non-permitted origin while

delivering no event to the page. Verified both ways: on a permitted origin the
same call navigates the page; on a non-permitted one an in-page listener
records nothing and location.href is unchanged. Silent false success is the
worst failure mode for agent automation — it reports work it did not do.