Browserlane Desktop

What it is

Browserlane Desktop is the optional human interface over an existing bl installation. bl is the canonical, required runtime — it drives Chrome, serves the MCP tools, runs the daemon, and records the traces. Desktop is not a separate product, not a separate runtime, and not a way to start using Browserlane.

Desktop serves the human. bl serves the agent.

Everything Desktop shows comes from what bl already recorded. When an agent drives the browser, the trace captures what actually happened: every command it issued, and — at the debug and forensic capture levels — the screenshots, console lines, and network requests of the session run. Desktop's job is to turn that folder of events into something you can read.

What exists today

The repo contains a partially built, read-only trace viewer. It reads the traces bl writes to disk and nothing else: it does not drive the browser, does not invoke bl, and does not talk to the daemon. It is not released, and the only way to run it is building the crate from source.

Because a trace is an append-only log on disk, an open trace's timeline fills in as bl writes to it — but that is file tailing, not session monitoring. The viewer only ever sees sessions that were traced in the first place, and tracing is off unless you set BL_TRACE.

How you will install it

There will be one initial installation path, and it is the Binary. Desktop is a second, optional step on top of it:

# 1. Install Browserlane (this is the whole product)
curl -fsSL https://browserlane.com/install.sh | sh

# 2. Optional: add the Desktop UI (planned — not available yet)
bl desktop install

If you never want a UI — in a container, on a server, in CI, or behind an agent — stop after step 1. That same bl installation is the agent runtime.

Planned capabilities

Planned, not shipped. The viewer codebase implements much of the reading side already, but Desktop is not released, so none of this is available today.

• Timeline of tool-call steps — events grouped into tool-call steps, with console output, network requests, and screenshots attributed to the call they occurred under (best-effort — evidence outside a call's window appears unattributed). Each step shows its duration and status; failed steps auto-expand.
• Failure triage ("What broke?") — the last failing tool call, the sequence from last-ok to failed, related console errors and failed/5xx requests, and the last screenshot before the failure — each a click-through to its event.
• Network & console tabs — a DevTools-style request table (method, status, type, host, path, duration) with request-to-response correlation, failed-only and resource-type filters; a console view with level filters and page errors flagged.
• Screenshot filmstrip & artifacts — step through screenshots one at a time, jump straight to the first failure, or browse everything the run captured.
• Run browser — search, status and time filters, and sorting across recorded runs; repeated runs of one session name group as "run k/n".
• Live sessions — read session status from the daemon bl already runs, so the UI reflects what is actually running rather than only what was traced.
• Event inspector — sanitized arguments, a result preview, redacted headers, and the raw JSON for any event.
• Trace management — reveal a trace in your file manager, export it as a .zip bundle, or delete it.
• Capture level & redaction status — surface each trace's capture level and what was redacted.

How it will work with bl

None of this is implemented yet; bl desktop install does not exist.

Traces come from the recorder built into bl: set BL_TRACE=normal|debug|forensic and each session run is recorded as one folder — session metadata, an append-only event log, and an artifacts directory (see the tracing guide). That part is real and shipping today.

The planned relationship between Desktop and bl is deliberately narrow:

• One bl on the machine. Desktop will not bundle or embed a second copy of the Binary.
• Desktop will use the Binary you installed. bl desktop install will record that Binary's absolute path, version, and install identity, and Desktop will invoke exactly that path — never searching your PATH for some other bl.
• Shared state. Desktop and bl will share one daemon, one Chrome cache, one session store, and one trace store. There will be no second daemon.
• One version. Desktop and bl will carry exactly the same version during v0.x, and bl desktop install will fetch the Desktop artifact matching your installed Binary. If the registered Binary is ever missing or mismatched, Desktop will say so and point you at a repair or update — it will not quietly run something else.
• bl will own the lifecycle. Updating, repairing, and removing Desktop will go through bl, so Browserlane updates as one unit.

Privacy

• Local-only by design. The app makes zero network requests and has no telemetry.
• Redaction happens at capture time, in bl, before anything hits disk: sensitive key names, JWT and card-number patterns, and the values typed into sensitive fill targets are masked. This ships today, independently of Desktop.
• Built with Tauri v2 — a Rust backend and a React front end, nothing cloud-hosted.

Availability

Desktop is in active development; availability will be announced on browserlane.com. It will arrive through bl desktop install rather than a separate download, and will match your installed bl version.

In the meantime the trace format is documented (schema v1) and traces are plain JSONL — you can already read today's recordings with a text editor and jq. The trace schema is versioned independently of the app, so a future Desktop can still open the traces you record today.