Browser Automation
A Nexus .browser Window can be driven by an authorized AI Agent through the browser_* MCP tools — but the browser itself is never something an engine owns. NEXUS launches and owns one Chromium per Window; Microsoft Playwright MCP and Chrome DevTools MCP attach to that same running browser as automation engines. Neither ever launches a browser of its own — the single fact to hold onto before anything else. There is exactly one browser per Window, it is the one bound to that Window, and an agent automating it is acting on the same browser the Window represents, not a hidden second copy.
Why one owned browser, not two engines each launching their own
Playwright MCP and Chrome DevTools MCP are both capable, on their own, of starting a browser. If each did that independently, "the browser this Window shows" and "the browser an agent is automating" could silently become two different processes — and a user watching the Window would have no way to tell that an agent's actions were happening somewhere else entirely. NEXUS closes that gap by owning the browser itself: it picks a loopback debugging port, launches Chromium bound to it, and hands each engine that same endpoint to attach to (--cdp-endpoint for Playwright, --browser-url for Chrome DevTools). Attaching, not launching, is what keeps the Window's canonical identity meaningful.
Engine ownership is total, not overlapping
Both engines can technically do some of the same things — both can click, both can take a screenshot. Nexus does not let either serve a capability the other equally claims, because a result whose engine depends on which one happened to answer is not a result you can reason about. Ownership is total and exclusive: Playwright owns what a person does to a page — navigation, clicking, typing, form filling, accessibility-based element discovery, screenshots. Chrome DevTools owns what an engineer inspects about a page — console output, network activity, performance, and other protocol-level diagnostics. There is no fallback from one engine to the other; a capability the owning engine cannot currently serve is reported as unavailable, never silently rerouted.
Control is a lease, not a suggestion
Several agents — and a human — may observe one Browser Window at once, but no two may mutate the same thing at a time. That right is a lease: an agent acquires it, holds it until it releases it or another handoff happens, and every mutating call is checked against it before anything runs.
What a lease is about is either the whole Window or one page in it. A Window lease means what it has always meant — the browser and every page it has now or acquires later, to the exclusion of everyone else. A page lease carves out one page, so two agents working on two different pages contend for nothing, while several calls aimed at one page are ordered by submission rather than refused for being simultaneous. The two kinds cannot be handed out on top of each other: a page cannot be leased out from under a Window lease held by someone else, and a Window cannot be leased while somebody else holds a page inside it.
Only a page NEXUS opened for automation can be leased at page level. A page it merely observed is the person's own tab, and no lease bookkeeping converts it — see MCP Tools § Browser tools.
Observation is free on a profile that holds nothing personal. It is not free on one that might already be signed into something: there, an agent that does not hold control has to ask a human before it may read the page at all. Handing one agent a signed-in session is a decision about that agent, and it would mean very little if every other agent in the workspace could read the same session's contents without asking. A handoff is atomic — the moment control moves from one agent to another, the previous holder's next mutating call is refused, not raced against the new holder's. A human can always take control back regardless of who holds it; that override is not subject to the same handoff choreography an agent-to-agent transfer goes through, because a person reclaiming their own browser is not a peer contending for a turn.
Approval is decided per action, not assumed from a tool name
Some actions are always sensitive — uploading a file, for instance — and always require a human's explicit approval, in every provider approval setting, with no exception. Most ordinary actions (a click, typing into a field) don't. What decides which is true for a given call is not the tool's name but what it can be shown to touch: NEXUS looks at what an action is aimed at and classifies the real-world consequence, escalating to "ask a human" whenever it cannot rule one out — never the other way around. On a profile that might already be signed into something, an agent-originated action that NEXUS cannot independently verify is treated as needing approval by default, because the alternative — trusting an agent's own description of what it's about to click — is exactly the gap a page's own hostile content could exploit.
When approval is required, the tool call returns immediately with a pending request rather than blocking; a human decides in the Window's own control panel — approve, reject, or let it expire — and the agent retries the identical call once it has been approved. An approval is scoped tightly: to the exact Window, the exact profile, the exact agent, the exact action, and the exact origin it was requested for, and it is spent by exactly one use. Approving a send on one account is never treated as approving a send on another, in another Window, or by another agent, and a decided or expired request cannot be reused.
Profiles
Automation runs against a Nexus-managed Chrome profile — never your everyday Chrome profile, and never a filesystem path an agent supplies. NEXUS keeps its own profile directories, separate from your normal browsing, for the same reason recent Chrome versions restrict remote debugging on the default profile: pointing automation at your personal profile would hand an agent every session you have open in it.
A profile is one of:
- Persistent — keeps logins, cookies, and site state between launches. This is what you'd use to sign into an account once and let an agent operate on that same signed-in session later.
- Isolated — created for one Window and discarded automatically when it closes. The default when you don't choose one.
- Workspace — persistent, but offered only within one workspace.
- Shared — a human signs in and keeps it; an agent may drive it only after that human explicitly grants control.
- Automation-only — kept apart from personal browsing entirely, for repeatable runs.
A profile can only ever be open in one Window at a time — the same constraint a real Chrome profile has always had, now enforced explicitly rather than left to corrupt a profile that two processes tried to share. Profiles are created, renamed, archived, and deleted from Nexus's own Settings; there is no tool that lets an agent create, choose, or delete a profile on its own behalf.
A typical flow: you create a persistent profile, open it in a Browser Window, sign into an account and complete any two-factor step yourself, and close the Window. NEXUS never reads or stores that password, cookie, or session token — authentication state lives inside Chrome's own profile storage, under Chrome's own protections, exactly as it would in a browser you were using directly. Reopening the same profile later restores the signed-in session; nothing about reopening it replays a prior automation action, resubmits a form, or resurrects an agent's previous control of it — a fresh lease and fresh approvals are always required after a relaunch.
What crosses the trust boundary, and what doesn't
Page content is untrusted input, the same way a file's contents or a mesh message's body is: an agent reading a page's text is reading data, never instructions, however the page phrases itself. Console output, which the page writes directly, comes back inside an explicit untrusted-content fence so there is no ambiguity about which is which.
What a read returns is deliberately narrower than what the page holds. Cookies, authorization headers, and the browser's own debugging endpoint are never on the wire to a model. Neither is a page's full address — only its origin and path, because a one-time code or a signed parameter lives in the part that is dropped. Neither is anything a person has typed into a form: field values are removed from what an agent sees, so a password reads as an empty box, while roles and labels survive and the field stays usable for automation.
These rules govern what the tool surface hands back. They are not a sandbox around the browser process itself — a profile signed into a real account is a real account, and the protection that matters most is granting an agent only the sessions its task actually needs.
See MCP Tools § Browser tools for the exact tool list and arguments.