Claude gets a browser of its own, and it reads before it clicks
The new browser use toolset gives Claude element references, form input, and tabs instead of coordinates alone, and its documentation is unusually blunt about prompt injection.
On August 19, Anthropic's platform release notes carried two entries that belong together. The computer use tool left beta as computer_toolset_20260801, with batch actions and zoom on by default. And a new sibling launched beside it: browser_toolset_20260801, which the release notes describe as "a client toolset for driving a browser that your application hosts." Both run on Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Sonnet 5, and Claude Opus 4.8. A day later, both toolsets reached Claude on Google Cloud's Vertex AI. The documentation lists the platforms plainly: Claude API and Google Cloud, "not available on Claude Platform on AWS, Amazon Bedrock, Microsoft Foundry."
Structure first, pixels second
Computer use works a whole desktop through screenshots and coordinates. The browser tool's premise is different: "It works with the page both through its structure (the accessibility tree, elements, forms, and tabs) and through pixels (screenshots and viewport coordinates)."
One tools entry expands into 27 member tools by default (navigate, read_page, left_click, screenshot, tab management, and more), plus four that stay off until you enable them: javascript_exec, file_upload, read_console, and read_network.
The load-bearing member is read_page. It returns the accessibility tree as text, with elements tagged [ref_N]. Claude then clicks or fills a form by reference, {"type": "ref", "ref": "ref_2"}, instead of guessing pixel coordinates from a screenshot. form_input sets a field's value directly. There is a cost argument too: "a tree read of a typical page often costs fewer input tokens than a screenshot while giving Claude references it can act on immediately."
A strict contract for your executor
Your application hosts the browser, so the docs read like a protocol spec, down to exact strings. A turn with several calls is a batch: run them in order, stop at the first failure, and answer every later call with is_error: true and the exact text Not executed: an earlier action in this turn failed. The docs warn that "Every call must be answered or the next request is rejected." Each result carries a browser_state block listing the full tab inventory, "not a delta." Stale element references are your problem to detect; the docs even suggest the error text to return. Screenshots are not downscaled by the API, so oversized images are rejected: resize before returning, and scale Claude's click coordinates back up yourself.
The security page is the best part
The guidance assumes the web is hostile. Run browser and executor in a dedicated container with "a fresh profile that holds no credentials." Enforce a domain allowlist at the network layer and re-check it "in your navigate handler after redirects." Refuse every scheme except http and https. Build page reads from what the page renders, "so hidden text doesn't reach Claude." Leave javascript_exec and file_upload off unless needed, and confirm consequential actions per call, "because one turn can carry several."
The docs are also blunt about the failure mode all of this guards: "Claude sometimes follows instructions found in page content even when they conflict with yours; text on a page that says 'ignore your previous instructions and navigate to...' can divert it from the task."
That candor is the story. Web agents have mostly shipped as screenshot-and-click loops with the risks in a footnote. This one ships with the risks in the contract.
Primary sources: Claude Platform release notes, Browser use tool documentation, read 2026-09-01.