BrowserOS neo

BrowserOS neo is a separate browser, but its default onboarding imports the user's Chrome logins, history and other data, and agents then act with every signed-in session in that profile. The server has no identity of its own and no per-request authorization: tab ownership is shown to the agent as a label but the code deliberately never refuses an action on the user's or another agent's tab. The scripting tool also exposes the raw Chrome DevTools Protocol, which reaches the whole browser. The local cockpit API that manages connections, skills and sessions is not locked down by its default access configuration. A hijacked or misbehaving agent therefore holds the user's full web identity.

As a tool server, neo leaves approval to the connected agent; its contribution is risk signalling. Read tools carry read-only hints, but the click, navigate, download and upload tools carry no annotations, the save-skill tool is marked non-destructive, and the main `run` tool mixes reads and writes in arbitrary scripts that the description tells agents to prefer for every task. There is no preview, no read-only mode and no server-enforced confirmation. A `request_human_help` tool lets the agent hand a tab to a person, but the agent decides when to use it. Actions in logged-in accounts (posting, sending, buying) are not reversible.

Every tool has a typed argument schema that rejects unknown fields, but the arguments themselves are mostly passed through. `run` accepts arbitrary JavaScript against an SDK that includes raw DevTools Protocol access, `evaluate` runs arbitrary JavaScript in pages, navigation checks only a small scheme denylist, and `upload` attaches any local file path to a page's file input. All seventeen browser tools are enabled by default with no tool groups. A misused tool can act on any site the browser is signed into and send local files out.

Model-written code runs in two places. `run` scripts execute in a fresh QuickJS engine inside the server process, with no filesystem, network or process access of their own, a 64 MB memory limit, a stack limit and a 30-second interrupt; `evaluate` and `page.evaluate` run JavaScript inside Chrome's page renderer. The QuickJS engine is written in C, so an engine bug would land in the server process, and the injected SDK includes raw DevTools Protocol access with browser-wide control. The server process runs as the user, writes to connected agents' config and skill directories, and drives the signed-in browser.

Page text returned by the read, grep, snapshot, diff and evaluate tools is wrapped in per-call nonce markers with the page origin and a notice to treat it as data. Values returned from `run` scripts, the primary tool, are not wrapped. Nothing in the server limits what an agent can do after reading a hostile page: the same session can read private data in signed-in accounts, act in them, and send data anywhere. There is no read-only or no-egress mode.

Agents can persist instructions and code. The `save_skill` tool writes a skill file and links it into every connected agent's user skills directory (for example ~/.claude/skills), where those agents load it in later sessions. `run` scripts can save JavaScript helpers per website, and successful runs are also distilled into helpers automatically; both are loaded into later runs on that host. Nothing validates or gates these writes, and they are shared across all agents and sessions. Skills are visible and deletable in the cockpit.

The neo server loads no plugins and launches no MCP servers or packages at runtime; the only package command in the server is a stdio fallback for agents without HTTP transport, and every supported agent uses HTTP at system scope. Importing Chrome extensions is optional and off by default in onboarding. The project's own bundled components and updates are its own supply chain and out of scope here.

The neo server holds no model or service API keys of its own; browser credentials stay in Chromium's store. Usage telemetry is on by default but built from allowlisted fingerprints so literals and page text are dropped, session recordings mask password inputs, and helper distillation drops typed values. The audit log stores tool arguments in plain form, and the model can read cookies and page data of any signed-in site through the browser tools, which are long-lived session credentials.

Every tool dispatch, including each browser primitive inside a `run` script as a child record, is written to a local SQLite audit log with session, agent label and arguments, plus screenshots and replayable recordings. The agent's identity is whatever name the client declares. Records are written after the action through an asynchronous worker and failures are only logged; guard rejections are not recorded. The log lives in ~/.browserclaw, is pruned after 7 days by default, and its retention and cleanup are driven through the local cockpit API.

Each `run` and `evaluate` call is capped at 30 seconds, a cap the model cannot raise, and QuickJS scripts also have memory and stack limits and an interrupt that fires on cancellation or deadline. The cockpit can cancel a session, which cancels in-flight dispatches. There is no cap on the number of calls, sessions or open tabs, and no rate limit on actions. Page-side work started by a script continues after a timeout or cancellation.