Claude in Chrome: a page still in its loading skeleton and a genuinely empty page return the same successful no-match result to read_page, find and javascript_tool

## What happens

When a single-page app is still rendering its loading skeleton, `read_page`, `find`, `get_page_text` and `javascript_tool` all return a successful result with nothing in it: `find` reports no matching elements, `javascript_tool` returns `[]` for a DOM query, `get_page_text` returns the shell title only. A page that has finished loading and genuinely contains nothing returns exactly the same thing. There is no field, status or error that says "the document has not settled", so the caller cannot branch on it.

The only strategy available to an agent is to wait and query again. That is an open loop with no exit condition, because the signal that would end it (the page yielded something) is the same signal the loop is waiting for.

## Measured

One session against X Ads Manager (ads.x.com) on 2026-09-10, where the campaigns table wedged in its skeleton after repeated navigation:

- 75 `browser_batch` calls carrying 419 actions, 144 of them pure `computer` waits totalling 1,178 seconds
- 23 consecutive API calls that read 16,282,161 cached tokens and produced 6,113 output tokens, every one a wait plus a read that came back empty
- 252 tool results in the session; 7 carried a failure string, the rest were success with no matches
- three clicks on a toggle switch each reported success while the switch stayed `disabled` and the row unchanged, with nothing in the console or network log

Opening a fresh tab cleared the skeleton immediately. The agent had no way to know that the six 40-second waits before it were not going to work.

## What would close the gap

Any one of these would give the caller something to branch on:

1. A settled flag on read results: `document.readyState`, pending navigation, and whether any network request started in the last N ms, returned alongside the result of `read_page`, `find`, `get_page_text` and `javascript_tool`.
2. A `wait_for` action on `computer` (or a separate tool) that takes a selector, text or predicate and a timeout, and reports `settled` versus `timed_out` as a distinct outcome instead of a plain success with no matches.
3. Failing that, a distinct result string for "no matches on a page with pending network activity" so a caller can tell it apart from "no matches on a quiet page".

The first is the smallest change and the one an agent can act on without a new tool: two empty reads with `settled: true` is a real absence and stops the loop; two empty reads with `settled: false` is a rendering problem and the fix is a fresh tab, not more waiting.

## Environment

Claude Code desktop app on macOS (Darwin 25.6), Claude in Chrome extension, Chrome stable. Tools: `mcp__claude-in-chrome__browser_batch`, `read_page`, `find`, `get_page_text`, `javascript_tool`.

Start by reading the entry points for browser_batch, read_page, find, get_page_text, and javascript_tool, then trace how empty results are represented during the loading-skeleton scenario. Done means callers can distinguish a settled empty result from a document with pending activity across the affected tools, with the behavior covered by relevant tests.

索引モデルが issue の本文から書いたものです。