Cua Driver 0.19: Extension-Free Browser Use for Coding Agents

Published on August 6, 2026 · Source: Cua blog and Cua Driver docs

On August 6, 2026, the team behind Cua shipped what they call the first extension-free browser-use interface built into a unified computer-use driver. Stable in Cua Driver 0.19.0, the release connects an exact Chromium tab to its native process and window, so an agent can use semantic browser actions and full desktop control inside a single session. No Chrome extension, no separate browser to sign into, no cookie import dance.

If you build with coding agents, this is one of the cleanest takes on the browser problem I've read this year.

The trade-off every browser agent still asks you to make

Every browser-use agent I've tried in 2026 starts with the same awkward choice:

• Give the agent a separate browser, sign in again, accept the friction.
• Or hand it a Chrome extension in the browser where you already work.

Both work. Both also make the browser into a special environment, with its own profile, its own auth, its own quirks. As Francesco Bonacci writes in the launch post, "the browser was not a separate world. It was another native application, with an unusually rich page interface behind it."

Cua Driver 0.19 connects those two views precisely. The driver proves that one OS window and one browser tab describe the same surface, then exposes typed browser actions to the agent inside that exact binding. The harness can pick the right interface at each step: local shell, typed browser state, native accessibility, or page screenshots.

One exact connection, not a guessing game

Under the hood, Cua Driver talks to Chromium through the Chrome DevTools Protocol (CDP). CDP can inspect a document, target an exact tab, and perform declared actions without borrowing your keyboard or physical pointer. That's the page-aware half.

The hard part is identity. A browser has two of them:

• The OS sees a process and a native window.
• The browser runtime sees DevTools targets and tabs.

Before mutating anything, Cua Driver proves both identities point at the same surface. It verifies the loopback DevTools endpoint belongs to the requested process, correlates the native window with the browser, and returns opaque capabilities for the target and tabs. Capabilities live inside one named session. Element refs live inside one semantic snapshot. Navigation, reconnection, a newer snapshot, or session end invalidates the old handles — the agent must re-inspect fresh state instead of acting on stale assumptions.

The public loop stays small:

1start_session
2list_windows
3get_browser_state(pid, window_id, session)
4get_browser_state(target_id, tab_id, session, semantic_v2)
5browser_navigate / browser_click / browser_type / browser_pointer
6get_browser_state(target_id, tab_id, session, semantic_v2)
7end_session

The first get_browser_state call binds the native window. The next returns a semantic outline plus short-lived action refs. A fresh snapshot verifies the result.

Cua Driver can address an exact inactive tab without foregrounding the browser. It does not guess which tab is active from list order, and it does not silently swap a trusted pointer action for a JavaScript click. Proven routes act. Ambiguous or unsupported routes return structured refusals.

A second killer detail for coding agents: the physical pointer stays untouched. In the demos, the agent's terminal stays in the foreground while Chrome is driven in the background. Inactive tabs stay addressable without becoming visible. You can keep working in your editor while a long-running agent churns through browser tasks elsewhere.

Explicit boundaries because CDP is a loaded gun

CDP has broad authority over a Chromium profile. Cua Driver never enables remote debugging as a side effect of inspection. Setup requires a separate browser_prepare operation, and the recommended route is a driver-owned isolated profile that is removed when the session ends.

Attaching to an existing signed-in Chrome or Edge profile is more sensitive. A standalone runtime needs an explicit launch grant like --grant existing-profile, or an embedding application must authorize the exact resource through its host callback. An agent cannot promote its own permission mode while it is running.

For unattended work, bounded mode is the recommended path. A reviewed YAML manifest declares the resources and tools the agent may touch:

1version: 2
2mode: bounded
3expires_after: 8h
4idle_timeout: 30m
5
6allow:
7  tools:
8    - start_session
9    - end_session
10    - list_windows
11    - browser_prepare
12    - get_browser_state
13    - browser_navigate
14    - browser_click
15    - browser_type
16
17resources:
18  apps:
19    - bundle_id: com.google.Chrome
20      launch: false
21      windows: all
22      terminate: deny
23  browser:
24    profiles:
25      - kind: existing_profile
26    origins:
27      - https://app.example.com
28  desktop:
29    display: false

Launch it with:

1cua-driver serve \
2  --permission-mode bounded \
3  --session-policy ./cua-session.yaml \
4  --approve-session-policy

The example uses Chrome's macOS bundle id; Windows and Linux use the canonical absolute executable path. Generic desktop input is deliberately omitted because it could bypass the origin restriction.

There is also an unrestricted mode (--dangerously-bypass-approvals) that accepts full agent control after launch-time acknowledgement. The docs make the trade-off explicit: use it only in disposable VMs or environments whose data exposure you accept. "No extension" does not mean "no consent." It means setup and authority are explicit and inspectable.

Where this fits in the 2026 browser-agent landscape

Cua is not the first to put a browser in front of an agent, but the approach is genuinely different:

• Claude Code connects through a Chrome extension that shares your signed-in browser state and exposes browser tools.
• Codex offers an in-app browser with a separate profile plus optional full CDP access, and a separate Chrome extension for existing tabs.
• Cua Driver puts the bridge below the agent, inside an agent-neutral computer-use driver. It works through CLI, MCP, Python, and TypeScript. The agent host does not need to own a browser integration.

That last point matters if you build agents for other people. Cua Driver 0.19 lets you ship browser automation without asking your users to install a Chrome extension or trust your binary with their real profile.

The OSWorld 2.0 ablation is honest

The launch post includes a paired ablation on 37 OSWorld 2.0 Chrome-related tasks (46 prespecified, nine deferred). Both arms ran on the same fresh 2-vCPU, 8-GiB Linux VM with GPT-5.6 Sol at medium reasoning, capped at 80 steps per arm and $35 per pair. The treatment added exact-tab CDP snapshots and typed actions on top of screenshot + accessibility.

Paired mean difference: +0.0255 (2.55 percentage points). 95% task-cluster bootstrap interval: −0.0054 to +0.0766. Exact paired sign-flip test: p = 0.5. Two wins, 34 ties, one loss. The direction is positive but not statistically significant at this sample size.

Cua is upfront about that. The qualitative signal is more interesting: typed tools helped most when a task required dense state across the page, exact element refs from a semantic snapshot, and stable addressability of multiple tabs without losing place. The cost roughly doubled per task and wall time grew about 13%, which fits the overhead of typed CDP actions on top of screenshot grounding.

If you run a similar ablation, publish the numbers. That kind of honesty is how the field moves.

Try Cua Driver 0.19 in your coding agent loop

If you build with Claude Code, the Codex app, Claude Cowork, or any MCP-capable harness, Cua Driver 0.19 is worth a weekend. Start with an isolated profile, add bounded mode when you need to touch your real sessions, and keep consequential decisions behind an approval prompt.

The browser is part of the computer. Cua Driver 0.19 finally treats it that way, without asking you to install an extension first.

Sources

• Cua blog: Blending the best of computer and browser use, without a Chrome extension
• Cua Driver docs: Drive a Web Page
• Cua on X: launch thread (5 tweets, Aug 6 2026)