Claude SDKs now run browser and desktop agent loops

Building a browser or desktop agent on Claude previously required a custom control loop. Applications had to parse each tool_use block, translate it into driver actions, return a matching tool_result, and repeat the process until Claude stopped requesting tools.

Anthropic’s Python and TypeScript SDKs now handle that loop through the browser and computer classes described in the toolset docs. A toolset bundles model-visible actions such as navigate, left_click, and type. Developers implement those actions against their preferred automation driver, while the SDK routes calls, invokes configured policies, collects approvals, and formats results.

The SDK takes the loop

The tool runner now parses Claude’s calls, dispatches them to the correct method, appends each result, and continues the conversation. Application code remains responsible for the browser or desktop environment, network controls, driver lifecycle, and the behavior of each implemented action.

Applications subclass BetaAbstractBrowserToolset20260801 or BetaAbstractComputerToolset20260801 and implement the supported members. The date-stamped names identify the beta tool versions. The SDK does not include a browser, desktop, driver, or default URL allowlist.

• The toolset instance itself goes in the request’s tools collection.
• Unimplemented members are sent to the API as disabled.
• If Claude still requests a disabled member, the SDK returns an error and continues the run.
• A failed call skips later calls to the same toolset within that turn.
• The runner leaves the toolset open after a run, so the application controls reuse, concurrency, and cleanup.
• Overriding execute adds hooks for tracing, redaction, validation, or input rewriting around every call.

Eager calls trade latency for finality

Eager execution can reduce latency by starting a tool call before Claude finishes streaming its response. The default runner waits for the turn to end. Python applications enable eager execution with stream=True and run_tools_eagerly=True.

An eager call continues after dispatch even if the response later stops at max_tokens, the stream fails, or the application ends the loop. The action may complete without Claude receiving its result. Purchases, messages, destructive edits, and other irreversible operations therefore need confirmation or recovery logic before eager execution is enabled.

Drivers stay interchangeable

Teams can connect the toolsets to their own Chromium, Playwright, CDP, VNC, or desktop automation layer. Browser Use, Browserbase, and E2B publish integrations, and Anthropic’s announcement also identifies Daytona. Anthropic provides a quickstart with a minimal CDP-based browser example.

The browser example implements navigate, screenshot, and left_click against a backend wrapper. Its _browser_state method reports open tabs and recent changes. A minimal desktop adapter follows the same pattern:

class MyDesktop(BetaAbstractComputerToolset20260801):
    def screenshot(self, context, input):
        return BetaScreenshotResult(
            data=self.display.png_base64(),
            media_type="image/png",
        )

    def left_click(self, context, input):
        self.display.click(input.coordinate, input.text)

    def type(self, context, input):
        self.display.type(input.text)

Policies stop at the network boundary

The browser class exposes a url_policy callback before each explicit navigate, a file_policy for uploads and downloads, and a confirm callback for actions that require approval. Several defaults affect deployment:

• Without a URL policy, the SDK performs no URL validation, and the Anthropic API applies no independent URL filter.
• javascript_exec and file_upload are disabled by default.
• Enabling either member without a confirm callback causes a configuration error during construction.

A URL callback alone cannot constrain requests triggered by clicked links, redirects, page resources, or browser internals. Those requests can reach loopback addresses such as localhost and 127.0.0.1, private network ranges, or link-local services such as the cloud metadata endpoint at 169.254.169.254. This creates a server-side request forgery risk that can expose internal services or credentials.

Effective containment combines the SDK policy with request interception in the driver and egress restrictions at the container or network layer. Credentials available to the browser should also use the narrowest permissions and shortest practical lifetime.

Desktop input receives tighter defaults because keyboard control can affect any focused application. A computer toolset that implements type, key, or hold_key requires a confirm callback unless its configuration disables those members. Keyboard input combined with a focused terminal can execute commands under the agent’s account.

One turn can use two toolsets

A request may include browser and computer toolset instances together. Each call carries a toolset_name of browser or computer, allowing the runner to dispatch it to the matching instance.

Failure isolation also follows the toolset boundary. When a computer call fails, the runner skips later computer calls in that turn while allowing scheduled browser calls to proceed. The same rule applies in reverse.

Fewer loop bugs, cheaper migrations

Moving control flow and result formatting into the SDK removes recurring implementation errors, including mismatched tool_use_id values, malformed result blocks, missing screenshots, and inconsistent handling after a failed batch. Applications can concentrate their tests on driver behavior, policy decisions, and recovery from side effects.

The shared interface also gives hosted and local drivers the same application-facing shape. A prototype using local Playwright can move to Browserbase, while a desktop agent can move between E2B and Daytona with changes concentrated in construction and configuration. The application’s prompts, tool routing, approval callbacks, and surrounding agent logic can remain stable.