Claude's SDKs run the click loop, but the browser is yours
The new browser toolset in Claude's SDKs comes with everything except the browser. There is no driver, no desktop and no URL policy, and the sample driver comes with Anthropic's own warning that it is not production code.
According to Anthropic's documentation, the Python and TypeScript SDKs now include classes for the browser use and computer use tools. The SDKs run the agent loop for you, and the browser, the desktop and the driver stay in your code.
At a glance
- Instead of writing your own loop, you subclass an SDK class and write one method per member tool, such as navigate or left_click, on top of an automation library like Playwright.
- The SDK routes each call, runs your URL policy, file policy and approval callback, builds each tool_result, and can start calls while Claude's response is still streaming if you turn that on.
- No browser, desktop, driver or URL policy ships with it, the quickstart CDP example is not production code, and of Anthropic's six safety steps the SDK applies only three.
If you haven't been following, computer use launched in public beta on October 22, 2024, alongside an upgraded Claude 3.5 Sonnet. As Anthropic's ClaudeDevs account put it on X, the API tells you what Claude wants to click or type, and until now you also had to write the loop that mapped those clicks and keystrokes to commands. According to Explainx, computer use and browser use became generally available on Claude Platform on Aug 20, 2026.
The SDK runs the loop, and Browser Use, Browserbase, E2B and Daytona supply drivers
A driver is your subclass of BetaAbstractBrowserToolset20260801. You write one method per member tool, such as navigate, screenshot or left_click, against your own wrapper around a library like Playwright. You also write _browser_state, the state report every driver needs. Then you pass the driver instance itself as the tools entry.
From there the SDK routes each call, runs the policies you pass, asks your approval callback and builds each tool_result. A member you don't implement goes to the API as disabled. If Claude calls it anyway, the SDK returns an error and the run continues. The runner never closes the toolset, so one instance can serve several runs, and closing it is your job.
If you'd rather not write a driver, Browser Use, Browserbase and E2B publish their own integrations, and the ClaudeDevs post adds Daytona to the list. To build your own, start from the example in claude-quickstarts. It comes in Python and TypeScript and drives Chromium through the Chrome DevTools Protocol.
With run_tools_eagerly, calls start mid-stream and cannot be taken back
By default, the tool runner executes a turn's calls after Claude's response ends. Pass stream=True and run_tools_eagerly=True, as the quick start does, and it can start a browser or computer call while the response is still streaming. Each pass through your loop then hands you a stream instead of a message.
The checks still come first. Your URL policy, file policy and confirm run before every call, though confirm may now fire mid-stream. Calls in a toolset still run one at a time in the order Claude wrote them, and a failed call still stops that toolset's later calls in the turn.
Timing is where it gets risky. If the response is cut off, for example at max_tokens, or your loop stops early, an action that has already started still happens, and Claude never reads its result. Without the runner, you answer each call yourself and must stop at the first failure, giving every skipped call an is_error answer with its toolset_name and the exact text the docs require.
Claude reads every URL your driver reports, cut at 4,096 characters
Think of the SDK as a dispatcher at a taxi firm. It takes Claude's orders, checks them against your rules, passes them to your driver and writes up the trip report. After each call that returns a result, including refused and failed ones, it calls _browser_state, and your driver lists every open tab plus what changed: new tabs, downloads, blocked navigations and dismissed dialogs.
The SDK doesn't parse the URLs in that report. It turns control characters into spaces, trims the ends and cuts each URL at 4,096 characters. A data: URL's contents, a file: URL's path and any user name or password inside a URL all reach Claude. The SDK also leaves local paths in error text unredacted.
Errors go one of three ways. A ToolError reaches Claude as its message and the run continues. Any other exception also reaches Claude as an error result, with its class name and message. A ToolsetUsageError, raised for configuration errors, misuse, calls after close or any failure inside _browser_state, goes past the runner to your code and stops the run.
Anthropic lists six safety steps, and the SDK applies three
The docs warn that a page, or text injected into one, can try to reach internal services, pull files off the host or trigger actions with real effects. Before you point a driver at anything but a throwaway browser, Anthropic asks for six things. You need a URL policy, request interception in the driver, egress rules on the container, confined uploads and downloads, confirm on consequential members and a dedicated container or VM per session.
Steps one, four and five run through the policies and the callable you pass to the SDK. Interception, egress and isolation are up to your driver and your deployment. The URL policy only sees the URL in a navigate call. It skips back, forward and reload, and it never sees clicked links, submitted forms, redirects or a page's own requests.
One default is deliberately strict. Pass url_policy=None in Python and the SDK refuses every navigate to a URL, so a missing config value can't switch checking off. Request hooks have blind spots too: they miss WebSocket handshakes, service-worker requests and redirect hops. The docs say to block service workers and check the other two with a hook that does see them.
The docs don't say how mature the partner integrations are or how well these checks hold up against real prompt injection. The only guidance is the six steps and a warning that the example policy isn't production grade. Oddly, overriding execute for something as small as a logging hook makes the SDK count every member as implemented. Claude is then offered default members your class can't serve until you switch them off with configs.
Managed Agents and Vertex AI dates
The Claude Platform docs say the new computer toolset isn't currently available in Claude Managed Agents, and they give no date for it. According to Explainx, updated computer and browser tools are coming to Google Cloud Vertex AI soon, also without a date. The docs don't describe a production driver from Anthropic, so for now an off-the-shelf driver means a partner's integration.
Related stories
- Opus 5.5 costs less and answers old agent code with 400s
- Claude Managed Agents get auto mode and a session viewer
- Claude's commerce agents ship as code, writes stay staged
- ant apply syncs Managed Agents from files in a repo
- Claude Fable 5.1 errors out if you edit past turns
- Computer use goes GA on the Claude Platform
Comments
No comments yet. Be the first.
Join the conversation
Sign in with Google to leave a comment. Your name and avatar come from your Google profile, and the comment appears after moderation.
