Cua adds extension-free Chromium control to its cross-platform agent driver

Why it matters

Browser agents often fail when work leaves the page. Cua is putting verified tab and desktop control beneath the model, while making permission scope part of the driver itself.

Francesco Bonacci (@francedot), founder of Cua, released browser control for the startup's computer-use driver on August 6th, giving AI agents a single interface for operating Chromium tabs and native desktop applications during the same session.

https://x.com/trycua/status/2085413700198916440

Cua described the feature in an eight-post thread on X as the first extension-free browser interface embedded in an agent-neutral computer-use driver. That first-of-its-kind claim is Cua's. The underlying release and technical documentation confirm the narrower product claim: Cua Driver can bind a selected Chromium tab to its operating-system process and window, then switch between browser actions and native controls without installing a Chrome extension.

Bonacci started Cua in San Francisco in 2025 after working at Xbox and Microsoft AI, according to Y Combinator. Cua's account of its founding says Bonacci and researcher Dillon DuPont had worked on Windows Agent Arena at Microsoft, a benchmark for agents operating desktop software. Bonacci later built Lume, an open-source command-line tool for running native macOS virtual machines on Apple Silicon, before entering Y Combinator's Spring 2025 batch.

The new browser layer extends that original bet: agents need access to the computer around the browser, including local files, terminals, permission dialogs and desktop software.

One session across the browser and desktop

Cua Driver uses the Chrome DevTools Protocol, or CDP, to inspect a page and issue typed actions such as navigation, clicks and text entry. Before allowing an action, the driver verifies that the browser target, native process and selected window refer to the same surface, according to Cua's technical launch post.

The driver then creates session-scoped capabilities and short-lived references to page elements. Those references expire after navigation, reconnection, a newer semantic snapshot or the end of the session. If the driver cannot prove the route to a tab or window, it is designed to return a structured refusal rather than guess.

That binding lets an agent address inactive tabs without bringing Chrome to the foreground. Inside a page, the agent can use structured browser actions. When a workflow opens a file picker, system prompt, terminal or editor, the same agent can fall back to native accessibility data and operating-system input. Cua says the physical pointer remains untouched during supported background actions.

The browser tools remain limited to Chromium-family browsers and Electron applications. Cua's known-limits documentation says Firefox and Safari do not receive typed browser mutation capabilities in the current release, while WebView2 and several WebKit-based application shapes return structured refusals. Cua also labels the typed browser surface preview-grade before version 1.0.

Cua says the browser interface is stable in Cua Driver 0.19.0 on macOS, Windows and validated Linux configurations. GitHub displays the tag as a pre-release, although Cua's release page says that label prevents the monorepo's global latest-release pointer from moving between separate products; the driver follows normal stable SemVer distribution channels. Developers can connect through the command line, MCP, Python or TypeScript.

Browser access expands the security boundary

An extension-free design removes one installation step, but CDP can expose a Chromium profile's open pages, cookies and local storage. Cua recommends that agents use a driver-owned isolated profile, which is removed when the session ends, unless a task requires an existing authenticated profile.

Attaching to an existing Chrome or Edge profile requires an explicit grant. For unattended work, Cua recommends a bounded permission manifest that specifies permitted tools, applications, browser profiles and origins. The documentation warns that unrestricted mode has no runtime Cua approval prompts and makes no prompt-injection safety claim.

Cua's origin restrictions also expose a practical compromise. A bounded browser runtime cannot combine origin-scoped typed browser tools with generic desktop clicking, because generic input could bypass the origin rule. Workflows requiring both surfaces need separately scoped runtimes, with the desktop runtime prevented from reaching browser windows.

Cua's early benchmark is inconclusive

Cua tested the browser layer on 37 valid paired tasks selected from OSWorld 2.0, a 108-task benchmark covering long-running workflows across websites, desktop applications and local files. Each arm used GPT-5.6 Sol at medium reasoning for up to 80 steps.

Adding typed CDP state and actions raised the mean official score from 0.0043 to 0.0298, a difference of 2.55 percentage points. The treatment also cost more, averaging $7.57 per task against $4.49 for screenshot and accessibility control, and took 10.2 minutes rather than nine minutes.

The result does not establish a performance gain. Cua reported two wins, 34 ties and one loss, with a 95% bootstrap interval ranging from -0.0054 to 0.0766 and a paired sign-flip p-value of 0.5. The test used a development build based on Driver 0.12.6 rather than the public 0.19.0 binary, and nine of the 46 selected tasks were deferred instead of counted as failures.

Cua's own conclusion is narrower: exact browser actions can improve grounding when agents must inspect dense state across multiple tabs, while planning and task orchestration remain unresolved. The launch puts that browser access below the model and agent host, giving developers one driver that can follow a workflow when it leaves the page. Whether models can use the added authority reliably remains the harder problem.