#Agent sandboxes

An agent sandbox is an ephemeral Docker container that runs for the duration of one agent session and is destroyed when that session ends. Every session gets its own sandbox, fully isolated from others running at the same time.

#What runs inside

The sandbox is where the agent does its work. It contains the project repository, the platform CLI (swecli), and the agent runtime. The agent reads files, runs commands, and writes code there. It calls back to the platform through swecli for knowledge, artifacts, and work items, and it can browse the web through a shared headless-Chrome service when browsing is enabled.

Nothing the agent does inside the sandbox outlives the session. Source changes are written to the repository before the sandbox is torn down; any other state is discarded.

The sandbox is a full coding environment. The agent installs dependencies, builds the project, and runs its tests, and it can bring up databases and services to run the whole application and check the result before you see it. How that environment is prepared from your stack, and how the agent builds a bigger one when a task needs it, is covered in Dev environments and Preview environments.

#When a sandbox is created

A sandbox starts when you open a new agent chat. The platform creates the container, mounts the repository, and waits for the agent runtime to signal readiness before the chat accepts your first message. Resuming an existing chat from your history reuses that session's record but starts a fresh container.

Agent work that runs without a chat window, such as artifact generation or implementation jobs, also runs in sandboxes. Those sandboxes are created and destroyed by the platform automatically; they are not visible in your chat history.

#The project shell

Project chat and automations run their commands in one shared shell per project. It starts in the background as soon as you open the project, so your first chat does not wait for it. It stays up for an hour after the project was last used, and opening the project, starting a chat or running a command each count as use.

#Lifecycle

A sandbox goes from created to active once the container is healthy. While active, the agent sends a heartbeat every five minutes. If three consecutive heartbeats are missed, the sandbox is treated as idle and reaped. A session that runs longer than the platform maximum lifetime is stopped at that boundary regardless of activity.

On destroy, the platform revokes any credentials the sandbox was issued, removes the container, and releases its slot in the session registry.

#Next steps

• Hardened mode: restrict network access and tighten execution controls.
• Preflight checks: what the platform verifies before an agent run.
• Agent web browsing: how the agent reads web pages inside a session.
• Dev environments: the toolchain a sandbox starts with, and how the agent builds a bigger one.
• Preview environments: run the built application and click through the result.