Skip to content
PRESHaiPRESHaiPRESHos Platform

Sandbox

Open in product: preshos.com/agent-ops/sandbox

The sandbox is the isolated execution space a session runs inside: the runner, repository linkage, and runtime the agent acts through. It is where commands run, files change, and tools execute — separated from the member’s device and from other tenants by the environment boundary. The environment also sets the sandbox timeout: long work gets a longer leash, routine work does not.

What it is

Section titled “What it is”
  • One session runs in one sandbox under one environment. The environment defines the runner, repo, runtime, tool grants, and secrets the sandbox starts with.
  • The sandbox is disposable working state, not storage. What matters leaves as an artifact or a recorded outcome; the rest stays behind.
  • Isolation is the point. The agent reaches only what the environment grants — same guarantee as every governed session.
Session sandbox: isolated runtime with runner, repository linkage, and file state

How to open it: Inspector surfaces

Section titled “How to open it: Inspector surfaces”

Members work through the Inspector, not a raw shell. There is no direct user shell into the sandbox, and there is no separate Preview kind: a preview_requested signal lands in the Browser tab, which renders the output for review.

  • Browser shows the hosted session browser and renders requested previews: the Playwright-driven browser that belongs to the session, with its own history, cookies, and logins. This is the hosted Eve browser — it is not the member’s Chrome and not a Chrome extension session. See Browser use.
  • Manual carries direct commanded steps: what the agent ran, in order, with results. Members read it; they do not get a prompt in it.
  • Files shows the working tree: live scratch state beside the durable artifacts. Scratch is safe to overwrite; artifacts are versioned reviewables. See Working folder vs artifacts.

Manual carries the run’s commanded steps in order with results. The surrounding inspector holds the rest of the run state: prompt and child-agent lineage, the Files tab with working-folder state, and the resume decision with its approval composer — members read progress here, they do not get a prompt in it.

  • A run resumed on its connected host continues from proven transcript state, never from assumed device state.
  • Approval-gated steps pause in the activity feed until a human decides.
Session inspector with Files tab, working folder state, and run resume controls

The Browser tab is the hosted session browser: Playwright-driven, inside the sandbox boundary, with its own history, cookies, and logins. Empty, it waits for a URL or for the agent to open a preview — a preview_requested signal renders here for review.

  • This is the hosted Eve browser, not the member’s Chrome and not the cloud Preview.
  • No page loaded is a starting state, not an error; act-first without a snapshot is the error.
Inspector Browser tab with an empty hosted session browser awaiting a URL or preview

Members open Inspector surfaces through the tab menu: Files, Browser, Terminal. Files shows the working tree — here still empty, “no files written yet,” with the run’s environment and agent bound in Context below.

  • Scratch state is safe to overwrite; what matters leaves as a versioned artifact.
  • Missing files or missing repo context is an environment scoping problem, not a prompt problem.
Inspector tab menu offering Files, Browser, and Terminal above the working folder

Backends: Vercel vs. host

Section titled “Backends: Vercel vs. host”

Sandboxes run on two backends: Vercel or host. The environment decides which. Host-backed sandboxes carry the desktop bridge that computer use and local-Chrome claims need; a session that needs either and lands on a backend without one is a scoping question for the tenant admin, not a wording problem.

Hosted Eve vs. local Chrome: do not confuse them

Section titled “Hosted Eve vs. local Chrome: do not confuse them”
  • The hosted session browser (Inspector Browser tab) runs inside the sandbox under the session’s environment policy. History, cookies, and logins stay in the session boundary.
  • A local Chrome driven through the extension is a different surface: the member’s own browser, claimed per run through the chrome_browser plugin tools. It needs a host with a desktop backend, and reconnecting means a new run.
  • Full rules for the local path: Chrome browser. Never describe one as the other.

When the sandbox looks wrong

Section titled “When the sandbox looks wrong”
  • Builders verifying an environment open test sessions against it and read the results there. The probe sequence lives under FDE environment.
  • If session behavior suggests the sandbox is wrong (missing files, missing repo context, unreachable tools), treat it as a scoping problem: check the environment with the tenant admin.

What next

Section titled “What next”