What shipped.

In review. This work package is finished and under review; it is not on the hosted service yet. We will update this entry when it ships.

API

• POST /v1/tabs and MCP browser_open return live_url, live_mode (interactive or view) and live_url_expires_at for a new tab. A tab a page opens (a popup, target=_blank) carries its link the first time a listing reports it. live: "view" | "interactive" | "none" chooses; the mode never exceeds what the user's policy allows.
• Opening the link brings that tab to the front for the person, without changing the agent's default tab.
• Contract 1.10.0 (additive). The Python and TypeScript SDKs expose the link on a tab.

Dashboard

• The viewer fills the window under a slim bar: the user's tabs, back, forward, reload, an address box, full screen, paste, an on-screen keyboard on touch screens, and "Hand back to agent". View-only links show no input controls.
• Interactive links capture the keyboard with a visible hint ("press Esc twice to release"). The page refreshes its ticket while open and says plainly when a link has expired.

Reliability

• The viewer's controls are gateway calls through the same service layer as REST and MCP: address rules, allowed domains, the network guard and site policy apply unchanged. Every issued link and every control is in the audit log.

Pricing

• GET /v1/admin/usage?from=&to=&user= reports, per user and interval, browser-seconds (from browser start and stop), task tokens (input, output, cache writes and reads, model calls) and stored bytes, from a persisted usage log. The hosted console reads it to show usage and apply plan limits.

API

• Admin viewer tickets: POST /v1/admin/users/{id}/viewer-tickets gives the console a live view link for a user, under that user's own rules.
• Per-user controls: PUT /v1/admin/users/{id}/controls sets suspended (stops the browser and blocks the user's tokens with 403 account_suspended) and max_tokens.
• A user's tokens one by one: list them (id, label, last four characters, created, last used; never the secret), issue an extra token with a label (shown once), revoke one.
• Contract 1.9.0 (additive). Both SDKs gained the matching admin methods.

Reliability

• docker/seccomp-chromium.json is Docker's default seccomp profile plus clone, unshare and setns, which Chromium's namespace sandbox needs. Both Compose files and the hosted deployment use it.
• The entrypoint probes the sandbox at start. Without the profile it falls back to --no-sandbox with a warning and the fix, instead of failing.
• The "unsupported command-line flag" bar is gone from the live view.
• The hosted gateway runs with a container memory cap, a CPU cap and a per-browser memory guard.

More in the post Keeping Chrome's sandbox on in Docker.

API

• Python: pip install webpilot-si. Sync and async clients; tabs with every look and act method; vault logins; sessions, including cookie import; downloads as text or rows; recordings, replays, hand-offs, webhooks (verify_webhook) and tasks. Typed errors, retries that respect Retry-After, optional OpenTelemetry spans.
• TypeScript: npm install webpilot-si. The same resources as the Python SDK, for Node 22 and newer.
• The generated part of the Python SDK is now produced in one pinned Linux container, so every machine generates the same code.

Both SDKs live in the open repository under sdk/.

API

• Browser settings accept profile_enabled: true (off by default) for every site or per host. Each user then gets a stable generated identity (hardware concurrency, device memory, screen size, an OS-appropriate WebGL vendor and renderer) that survives restarts. Site rules can turn it off or override single fields.
• Clicks and hovers follow curved pointer paths; typing, key presses and vault fills use paced input. profile.humanize: false keeps ordinary input.

These reduce particular automation signals. Whether a site accepts a session still depends on the site.

API

• webpilot-si for TypeScript: WebPilot with account, tabs, sessions, vault names, viewer tickets, site memory, read, browser settings, files, recordings, replays, hand-offs, webhooks and tasks; Admin for user management.
• Examples for both SDKs (read a page, vault login, hand-off, record and replay, download) run against a local fixture site.

Dashboard

• A public landing page on the server, with a sign-up form. Sign-up can be open (a one-time email link creates the account and shows the token once), approval (requests wait in the admin console) or off.
• Lost tokens: /token emails a one-time link to a new token. Tokens themselves are never emailed.

API

• Examples served at /examples: Python and TypeScript scripts, MCP configs for Claude Code, Cursor, Codex and Claude Desktop, and curl.

On webpilot.si you sign up in this portal instead; the gateway's own landing page is turned off.

API

• POST /v1/webhooks {url, events}: handoff.resolved, handoff.expired, replay.finished, task.finished, recording.stopped, download.completed and browser.stopped, signed with WebPilot-Signature: t=<unix>,v1=<HMAC-SHA256>. Failed deliveries are retried after 1 minute, 5 minutes, 30 minutes, 2 hours and 6 hours; the last 100 deliveries are kept.
• POST /v1/tasks {goal, start_url?, max_steps?, max_tokens_total?, allowed_domains?, output_schema?} runs the goal through the same actions as any agent, so site policy, the vault and hand-offs apply. Output is validated against output_schema, and token usage is reported.

Reliability

• Webhook URLs must be https:// and resolve to public addresses, checked again on every delivery.

API

• POST /v1/read and browser_read: the main content of a URL as Markdown or text; PDF, DOCX, XLSX and CSV as text; YouTube transcripts. A 401, 403 or 429, a bot challenge or a page with no text without JavaScript is read again in the user's own browser, in a read tab that is closed afterwards.
• Cookie import: a Cookie-Editor or EditThisCookie export, a Netscape cookies.txt or a Playwright storageState becomes a saved session. Only counts and domains come back.
• Browser settings per user and per site: locale, time zone, geolocation, window size, colour scheme and an optional user agent, applied before each page load.

Reliability

• The server-side fetch connects only to public addresses: private, loopback and link-local ones are refused after DNS and on every redirect. One network guard now serves reads and webhooks.

Reliability

• At most CBU_MAX_BROWSERS browsers at once, derived from the container's memory (about 700 MB per browser). Extra requests wait in a queue for up to 30 seconds; a browser idle for 5 minutes or more is stopped to make room, with its tabs saved. Otherwise the answer is 503 browser_capacity with Retry-After. A browser someone is watching is never stopped for another.
• A memory guard per browser stops one that grows past its limit; it starts again on its user's next request.
• Idle browsers stop after 20 minutes (was 60).
• Run-report frames on scrolled pages now show what was on screen; before, they could come out blank.

API

• GET /v1/admin/status reports capacity and each running browser's memory.
• cbu doctor checks Node.js, the browser, CDP, the data folder and the vault key locally, or a remote gateway's TLS, token, MCP tools, a tab and a viewer link, with a fix for each failure.

API

• browser_record start and stop: a screenshot and a line for every action, also on background tabs. The report is one self-contained HTML file, plus a JUnit XML export.
• Hand-offs: a "Your turn" page with the agent's message, the user's browser live and a Done button; programs long-poll for the result.
• browser_record_script and browser_replay: a stopped recording becomes a script with ranked locators for each element and replays without an LLM, stopping at the first step it cannot do.

Reliability

• For a view-only ticket, the viewer's relay forwards only the messages needed to draw the screen and drops key, pointer and clipboard messages.

API

• PUT /v1/admin/users/{id}/policy: ordered rules per user, for example bank.example → read_only, then *.example.com → allowed. The first match wins. read_only refuses writes, logins, secrets and JavaScript with 403 site_read_only. Users see their own rules in GET /v1/me.

API

• REST v1 at /v1 on a service layer shared with MCP, so both behave the same.
• Errors are always {"error": {"code", "message", "hint", "details", "request_id"}}; every response has X-Request-Id and RateLimit-* headers; every POST accepts Idempotency-Key; lists use opaque cursors.
• The contract (api/openapi.yaml) and the SDKs are Apache-2.0.