How Sandpi Lets Humans and Agents Share One Browser

A coding agent can open a page and run a test. A human can open the same site and complete a login. If those actions happen in separate browsers, they do not share tabs, cookies, or the page the other person was looking at.

Sandpi gives each cloud Environment one headed Chromium desktop. The human sees and controls that desktop in Sandpi's Browser panel. The agent attaches to the same running Chromium process through Chrome DevTools Protocol (CDP). A login completed by the human is immediately available to the agent; a page opened by the agent appears in the human's view.

This is an application built on Sandbox0, not a browser feature built into every Sandbox0 sandbox. The distinction matters if you want to reproduce the pattern with your own application.

Two Ways Into One Browser#

The two connections have different jobs. VNC carries pixels, keyboard input, and pointer input for the human. CDP lets the agent inspect and automate pages. Both reach the same browser, so there is no synchronization layer copying tabs or cookies between separate sessions.

The browser also runs in the same sandbox as the development server. When the human opens localhost in Sandpi's Browser panel, it refers to the sandbox's loopback address, where the application under test is running. It does not refer to the human's laptop.

What Sandbox0 Provides#

The coding-agent template contains Chromium, Playwright CLI, Openbox, TigerVNC, and the dependencies needed to run a graphical browser on Linux. The template is prepared ahead of time. Claiming an Environment does not download Chromium or start a desktop.

Sandbox0 gives that Environment an isolated sandbox with a writable RootFS. It also supplies a command-backed Sandbox Service: when the Browser viewer first connects, the service starts the desktop stack on demand and routes authorized traffic to it. A resume-enabled route can bring a paused sandbox back before routing traffic to the service.

Sandpi configures that service for its own Environment. The service runs a virtual display and window manager, starts Chromium as a dedicated non-root user, and exposes a VNC transport through a WebSocket bridge. Sandpi's server authenticates the viewer and relays its connection. CDP listens on the sandbox's loopback interface for the agent; it is not published as a browser-facing service.

This is why Sandbox0 does not need a universal browser API. Its reusable pieces are the template, isolated runtime, persistent filesystem, service lifecycle, ingress policy, and resume behavior. Sandpi decides how its shared Browser should look and who may control it.

The Agent Attaches Instead of Launching Another Browser#

Sandpi makes the browser's local CDP endpoint available to Playwright CLI inside the Environment. The agent attaches to the running browser:

bash
playwright-cli attach --cdp=http://127.0.0.1:9222
playwright-cli tab-list
playwright-cli snapshot

attach is the important operation here. Starting a fresh browser would create a different process with a different set of live tabs. The shared instance lets an agent inspect the page where the human stopped, continue after an interactive login, or show the human the result of an automated action. As with two people editing one workspace, they should coordinate before operating on the same tab at the same time.

What Survives a Disconnect or Pause#

Closing Sandpi's Browser panel disconnects the viewer. It does not tell Chromium to exit, so the agent can continue working and the human can reconnect to the same running desktop later.

Sandpi stores the Chromium profile in the sandbox's persistent writable RootFS. Profile files, including cookies and local browser storage, survive an ordinary Sandbox0 pause and resume. A named RootFS snapshot can capture that profile along with the rest of the Environment workspace.

There are two Sandbox0 pause modes. A filesystem-only pause stops the desktop and browser processes; a later connection starts them again using the saved profile. Sandpi's intentional Environment pauses request a memory checkpoint. When that checkpoint and its restore succeed, supported guest process state can return, but the human's WebSocket connection still needs to reconnect. A RootFS snapshot captures files, not a live page or an in-flight browser action. The profile remains the durable fallback when processes are restarted.

The profile is also sensitive workspace state. A person who can restore a snapshot containing a logged-in profile may be able to use that browser login. Sandpi therefore keeps viewer access behind its authenticated server path and keeps CDP local to the sandbox; applications adopting this pattern should give browser snapshots the same access controls as the workspace they came from.

A Product Pattern, Not a Runtime Requirement#

Human and agent collaboration works here because both interfaces meet at one browser instance, while Sandbox0 keeps its runtime and durable state together. The browser dependencies belong to the selected template; Sandpi owns the viewer and automation experience. Other Sandbox0 applications can use the same primitives with a different browser stack or a different UI.

For the underlying lifecycle and template boundary, see Coding Agents on Sandbox0. For Sandpi's product experience, visit sandpi.ai.