Sandboxes

Every agent action in Disco Parrot happens inside a sandbox: a disposable container, isolated per piece of work, that the platform spins up and tears down for you. Most of the time the lifecycle is invisible, which is the point. The Sandboxes page under Platform is where you make it visible: a live list of every container running in your workspace, what each one belongs to, how recently it ran, and the controls to pause, destroy, or open one.

This page is the how-to for that surface. For what a sandbox actually is, the isolation model, the lifecycle, and why every run gets its own container, read sandboxed execution; for opening one in your editor, see open a sandbox in your IDE. This page is about managing the ones that exist.

The list

The Sandboxes list shows your workspace's active containers, one row each, and it refreshes itself every few seconds so what you are looking at is current without a manual reload. There is a refresh control too, for when you want it now. Each row carries what you need to recognize a sandbox and decide what to do with it:

• Status, as a colored badge, so running, paused, and failed read apart at a glance.
• Profile, the sandbox profile the container launched from, which tells you what kind of environment it is.
• Used by, the work the sandbox belongs to: the conversation, and the initiative behind it, so a container is never an anonymous box you are afraid to touch.
• Branch, the Git branch the work is on, when there is one.
• Last active, how long ago the sandbox last did anything, which is the column you sort by when you are deciding what to clean up.

When the list grows, you narrow it. A filter panel lets you show only the statuses you care about (just the running ones, say, or only the failed) and filter to a particular profile, and the filter lives in the page URL, so a view you build is a link you can share or come back to.

What each status means

A sandbox moves through a small set of states, and the badge on the row tells you which one it is in:

• Creating is a container coming up. Give it a moment; the work controls appear once it is running.
• Running is live and doing work. This is where the Inspect, Web Write, Desktop IDE, and Pause actions are available.
• Paused is stopped but holding its state. A paused container costs no compute, and it wakes itself the next time its work needs it, so a pause is a rest, not an ending.
• Failed is a container that could not come up or hit an error. It is safe to clear out, and the work it belonged to is unaffected.
• Destroyed is torn down. It lingers on the list for a moment, then drops off.

The lifecycle behind these states, idle auto-pause, resume on use, and the way a configuration change brings up a fresh container instead of a stale one, is covered in sandboxed execution. The list is where you read the current state; that page is where the rules live.

Acting on one sandbox

The actions on a row follow the state. A running sandbox offers the full set. Open it in your IDE to Inspect or Web Write, or hand it to your desktop editor. Pause it to park it without losing its state. Or Destroy it. A sandbox in any other state offers Destroy and nothing else, because there is nothing live to act on.

Pause parks a running container. The state is held, the compute stops, and nothing about the work is lost; the next time the same piece of work runs, the platform brings the container back. There is no separate resume button, and that is deliberate: a paused sandbox is not something you have to remember to restart, it is something that wakes on its own when its work calls for it.

Destroy tears a container down for good. Because the model treats sandboxes as throwaway, this is a smaller decision than it sounds: your code lives in your repository, the record of the work lives in the work model, and the conversation history is kept. What goes away is the container and its working state. The confirmation says exactly that before you commit, so destroying a sandbox is never a surprise about what you lost.

Clear out the inactive ones at once

A workspace doing real work accumulates sandboxes that have finished their job: paused ones nobody came back to, failed ones, the residue of a busy week. Rather than destroy them one at a time, the page header carries a Destroy inactive action that clears them in a single move, with a count so you know how many it will take. Inactive means exactly the states that are done contributing, paused, failed, and destroyed, so the action never touches a sandbox that is still running.

The action respects the filter you have on. If you have narrowed the list to one profile, the count and the cleanup are scoped to what you are looking at, so a lead doing a tidy-up on the Insights profile clears only those rather than the whole workspace. It is the difference between a scalpel and a broom: most days you reach for the broom, and the count tells you before you swing it.

Warm pools

Next to the active list sits a Warm pools tab. A warm pool keeps a small inventory of containers built in advance for a profile, so a person opening a chat or a flow run attaches to a ready container instead of waiting for one to build from scratch. The tab is where you see the live state of those pools, how many containers are ready right now, and clear them when you want to. You turn a warm pool on, and set its floor and ceiling, on the sandbox profile itself; the concept and the strategies behind it are covered under sandboxed execution.

Clearing a pool drains its ready containers, which you do when a profile's image has changed and you want the next attach to build fresh rather than land on a container prepared against the old recipe. The pool refills itself back to the floor afterward, so a clear is a reset, not an off switch.

Who can see and manage sandboxes

Reading the list rides on sandbox.read, so anyone you trust to see what the workspace is running can open the page. Pausing, destroying, and the bulk cleanup are held by sandbox.manage, the elevated scope your admins and operators carry, because they change what is running. Opening a sandbox in an editor is its own scope, sandbox.ide.access, covered under open a sandbox in your IDE. The split means a teammate can watch what is happening on the page without being able to tear a container down by accident.

A weekly tidy-up, end to end

It is Friday, and Priya leads the team behind the Insights service. A week of agent work has left a trail of containers behind it: a few Ask sessions that answered a question and parked themselves, a Flow run that failed when a test flaked, a handful of paused chats nobody came back to. She opens Sandboxes under Platform.

The list is busy, so she narrows it. She filters to the Insights profile and sorts by Last active, and the picture resolves: two containers still running, one of them the chat she has open in another tab, and below them a stack of paused and failed ones going back to Monday. She leaves the running pair alone. The header now reads Destroy inactive (6), scoped to the filter she set, so the count is the Insights residue, not the whole workspace.

Before she clears them, she catches one failed row she does not recognize and opens it in Inspect to read what went wrong: a missing environment variable the profile has since fixed. Nothing to keep. She clicks Destroy inactive, the confirmation names the six and what they leave behind, and she takes the sweep. The week's residue is gone, her two running containers are untouched, and the tidy-up took the length of a coffee. She did not file a ticket, and she did not ask an engineer what any of those boxes were, because every row told her what it belonged to.

Why the management surface works this way

The instinct, when a platform runs containers on your behalf, is to hide them completely: trust the automation, never look. That works right up until the day something is stuck, or costs are climbing, or a security review asks what is actually running, and then a black box is exactly the wrong thing to have. The Sandboxes page is the opposite of a black box. It does not ask you to manage the lifecycle, the platform still pauses idle containers and brings up fresh ones on a config change, but it lets you see the lifecycle and step in when you want to. The automation handles the common case; the page is there for the moment you need to look.

For a planner, the page answers "what is the agent doing right now" in one glance: a row per piece of work, with the initiative it belongs to, so the activity is legible without asking an engineer.

For an engineer, it is the fast path to a stuck or curious sandbox: filter to the failed ones, open the one you care about in your IDE, or pause and destroy the container you are done with, without leaving the page.

For a lead, the bulk cleanup is the weekly tidy-up made trivial: one filter, one button, and the week's residue of paused and failed containers is gone, with the count telling you the size of the sweep before you take it.

For the person who has to account for what runs in your infrastructure, the page is the answer to "what is live": every container, the work it belongs to, the profile it launched from, and the controls to stop it, all gated so that watching and changing are different permissions. A running sandbox is never anonymous, and stopping one is always one click and one confirmation away.