Anthropic SDKs add computer-use action loops for Python and TypeScript

• Python and TypeScript SDKs now run Claude's computer and browser action loops, according to the SDK announcement.
• Browser Use, Browserbase, E2B and Daytona provide compatible drivers, with custom implementations also supported in the launch follow-up.
• Cloud desktop integrations are already available: E2B's demo runs actions inside isolated machines, while Daytona's announcement points to disposable sandboxes.

Anthropic's SDK documentation includes an eager mode that can execute an action before Claude finishes streaming its response. The Browser Use quickstart enables 31 browser actions plus Bash, which stays on the SDK host even when the browser is remote. Daytona's sketchpad example gives Claude a drawing task without DOM access or an accessibility tree.

Anthropic moved the tedious click-and-keystroke dispatch into its Python and TypeScript SDKs. Claude proposes actions through the API; the tool runner dispatches them to a driver, returns the results and repeats until Claude finishes.

Both toolsets are beta, as announced alongside Haiku 5.5. Anthropic claims around 75% lower average running costs than Haiku 4.5 in the model launch post.

The SDK supplies the orchestration classes. Browser or desktop provisioning still comes from the application or its driver provider.

A custom browser driver subclasses BetaAbstractBrowserToolset20260801, following the SDK guide. The minimal example wraps an automation backend with these pieces:

• Action methods: navigate, screenshot and left_click, each receiving typed input and a call context.
• State reporting: _browser_state in Python or browserState in TypeScript reports open tabs and changes since the previous report. Exactly one tab must be active when tabs are open.
• Tool registration: the driver instance itself goes in tools.
• Capability detection: unimplemented members are advertised as disabled. Calls to disabled members are rejected before driver code runs.
• Cleanup: the runner never closes the toolset. One instance can serve multiple runs; the examples use a Python context manager or TypeScript try/finally.

TypeScript implementations must use methods rather than arrow-function fields because the SDK discovers them on the prototype. The typing action is named type_ in TypeScript and type in Python.

The runner normally waits for the model response to finish before executing its calls. Anthropic's early-start documentation exposes stream=True with run_tools_eagerly=True in Python, or stream: true with runToolsEagerly: true in TypeScript.

The execution rules remain:

• URL policy, file policy and confirmation checks happen before execution, including during streaming.
• A toolset executes calls sequentially, in the order Claude wrote them.
• A failed call stops that toolset's remaining calls in the same turn.
• An action already started cannot be recalled. If the response is subsequently cut off at max_tokens, the action still happens and Claude never reads its result.

Error handling also distinguishes recoverable action failures from harness failures. ToolError becomes an error result and the run continues; ToolsetUsageError stops the run, including when browser-state reporting raises an exception.

URL enforcement is supplied by the application. The SDK policy documentation describes several boundaries:

• Without a URL policy, the SDK checks no URL.
• The policy checks explicit navigate targets. Links, redirects and subresource requests can still reach hosts outside that check.
• Raising ToolError from the policy blocks the navigation and returns an error to Claude.
• Container-level egress restrictions cover network paths that navigation checks miss. Rules outside the container cannot see its loopback traffic.

Browser Use's integration requires a confirmation callback when enabling file_upload or javascript_exec. Its quickstart supplies confirm=lambda _: True, automatically approving browser actions.

Custom execute hooks have another sharp edge: they receive input after policy and confirmation checks, and the SDK does not revalidate input that the hook changes.

URLs returned by the driver are model-visible data. According to the state-reporting documentation, the SDK normalizes control characters and truncates URLs at 4,096 characters, but does not parse or redact them.

That includes tab URLs, download URLs and the URL returned by navigate. A data: URL's contents, a file: path or credentials embedded in a URL can therefore reach Claude; local paths can also appear in driver error messages.

Browser Use's integration guide documents three connection modes:

• Local Chromium: BrowserUse(). The driver starts and closes the browser.
• Browser Use Cloud: BrowserUse(use_cloud=True). The driver creates and stops the cloud browser.
• Existing CDP session: BrowserUse(session). The application owns the borrowed browser's lifecycle.

The integration requires Browser Use 0.13.11 or newer and an Anthropic SDK exposing anthropic.tools.browser and client.beta.messages.tool_runner. The guide explicitly warns that an Anthropic 1.x version constraint alone does not guarantee those modules exist.

Local mode needs ANTHROPIC_API_KEY; cloud mode additionally needs BROWSER_USE_API_KEY. The example requires Python 3.11 or newer and /bin/bash, with WSL specified for Windows.

Browser Use exposes 31 browser actions in its integration guide, grouped as follows:

• Navigation: navigate, new_tab, list_tabs, switch_tab, close_tab.
• Page state: screenshot, zoom, read_page, find, get_page_text, wait.
• Pointer: left_click, right_click, middle_click, double_click, triple_click, hover, mouse_move, left_mouse_down, left_mouse_up, left_click_drag, scroll, scroll_to.
• Input: type, key, hold_key, form_input, file_upload.
• Diagnostics: read_console, read_network, javascript_exec.

A bare BrowserUse() enables 27 actions. The quickstart turns on the remaining four through configs: JavaScript execution, file uploads, console reading and network reading.

javascript_exec runs inside the page, rather than acting as a general-purpose CDP interpreter. Bash is a separate registered tool, absent from tools=[driver].

E2B provides two drivers inside private desktop sandboxes, described in its integration guide:

• E2BBrowserToolset: controls Chrome through page elements, forms, tabs, navigation and the accessibility tree.
• E2BComputerToolset: controls the full Linux desktop through screenshots, mouse and keyboard input, including terminals and LibreOffice.

Both can share one desktop, allowing Claude to switch between browser automation and desktop applications or OS popups. The cookbook demonstrates reading LibreOffice Calc data, entering it into OrangeHRM and writing results back.

E2B's liveView streams the desktop over VNC. Stopping that stream does not destroy the desktop, and sandbox egress rules are fixed at creation rather than widened later by a URL policy.

Daytona's drawing guide uses DaytonaComputer from daytona-claude-toolsets to map toolset actions onto its Computer Use API. An uploaded paint.html opens in Chromium's app mode, with Claude locating controls visually and dragging to draw.

The example automatically approves actions because its desktop is disposable and deleted when the context manager exits. Daytona explicitly limits that rationale to the throwaway environment; a persistent sandbox has different trust implications.

A remote browser does not move every tool into the same environment. Browser Use's file-handling documentation separates the browser host from the SDK host:

• Bash stays local to the SDK process, including when use_cloud=True provisions a remote browser.
• Upload paths belong to the browser host. The application stages file bytes there before selecting them through file_upload.
• Document resolvers map IDs to paths, but do not transfer files.
• Download notifications report remote metadata, rather than making the downloaded file available to the SDK host.

BrowserUse(use_cloud=True) supplies neither automatic upload staging nor download retrieval. The Hacker News quickstart avoids that transfer boundary by having Bash write its Markdown and JSON outputs directly on the SDK host.