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

• 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.

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. HTML artifacts open here too — see Artifact versions. 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.
• Work item shows the thread’s linked work beside the transcript: one inspector tab per thread, with Back history, widening like Browser and document tabs. See Sessions.
• Files shows the working tree: live scratch state beside the durable artifacts. The tab picks live vs. saved itself — no Saved/Live toggle — and Download all sits in the ⋯ menu. 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.

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.

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.

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.

Git: per-session branches, checkpoints, and governed publish

Coding runs work on per-session Git branches bound at run creation: the session starts from its environment’s repository linkage on its own branch, so work in one run never collides with another. Along the way the sandbox records automatic turn-end checkpoints — the transcript stays the review record, the checkpoint is the restore point.

• Pushes go through the brokered sandbox path, not the member’s credentials. The session never holds raw Git credentials; firewall transforms carry what the push needs and nothing else.
• Publishing is HITL-governed: publish_branch and create_pull_request pause for a human decision exactly like other consequential actions. Protected and foreign repos are rejected — the run reports the refusal rather than working around it.
• Treat the product UI as the source of truth for branch naming, checkpoint visibility, and the exact publish approval shape. Mechanics this page does not name are not promised.

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

• 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

• Working folder vs artifacts: scratch state against reviewable outputs inside the sandbox.
• Document tools: the foundational PDF, spreadsheet, and Word packages sessions carry by default.
• Environments: the bundles sandboxes start from.
• Browser use: scoped web work in the hosted browser.
• Chrome browser: the local-Chrome extension path, kept separate.
• Computer use: OS-level control inside the same boundary.
• Starting a session: picking the environment that shapes the sandbox.