Open a sandbox in your IDE

An agent does its work inside a sandbox: a disposable container with a fresh clone of your code in /workspace. Most of the time you never need to open it, because the work comes back to you as a reviewable change. But sometimes the change back is not enough, and you want your own eyes on the room it came out of: to see exactly what state the agent left the files in, to reproduce something by hand, or to fix one line yourself rather than describe it to an agent. Opening a sandbox in your IDE is that: the platform hands you a time-limited session into the live container, in the editor you already use, for as long as you need it and not a minute longer.

This page is the how-to: the ways to open a sandbox, what read-only and read-write actually mean, how the session is bounded, and how to close it. For what a sandbox is and why every agent action happens inside one, read sandboxed execution; for the change policies that govern what an agent can do across the sandbox wall, see approved actions.

Three ways to open one

A running sandbox offers up to three ways in, and they split along two questions: do you want the browser or your desktop editor, and do you want to read or to write.

• Inspect opens the sandbox in a browser-based editor, read-only. You can browse the tree, open files, and read what the agent did, but you cannot change anything. It is the fastest way to answer "what did the run actually leave here," and because it cannot write, it is the safe default for looking.
• Web Write opens the same browser editor with editing turned on, so changes you make land back in the sandbox. It is there for the quick fix you would rather make by hand than describe to an agent. Whether it is offered at all is a per-sandbox-profile policy, because a profile that should never be hand-edited can leave the door closed.
• Desktop IDE hands the sandbox to the editor on your own machine, VS Code over Remote-SSH or JetBrains Gateway, through a small desktop companion app. This is the full-fidelity option: your extensions, your keybindings, your terminal, pointed at the container's /workspace over an SSH connection.

You open any of them from the Sandboxes list under Platform, where each running sandbox carries the buttons it supports. A sandbox has to be running to open: these are sessions into a live container, not a way to wake a paused one, so the controls appear only while the sandbox is up.

What read-only and read-write mean

The two modes are a real boundary, not a label. Inspect issues a session that can read the workspace and nothing else; the editor it opens has no path to write a file back. Write issues a session that can change files in the live container, and an edit you save in that editor is an edit in the sandbox.

The reason inspect exists as its own mode is that reading is the common case and writing is the one that deserves a decision. You almost always want to look, and looking should never carry the risk of a stray keystroke changing the container. So the default way in reads, and writing is a deliberate second choice you make when you actually mean to edit.

For the browser, that choice is also a policy your platform owners hold. Web Write is gated per sandbox profile: a profile can declare that browser write is off, and then a sandbox launched from it offers Inspect but not Web Write.

The desktop path sits outside that switch. Opening a sandbox in VS Code or JetBrains over SSH is its own capability, and the browser-write policy does not apply to it, so a team can keep the in-browser write surface closed while still allowing full-fidelity desktop editing over SSH, or open one without the other. The two surfaces are governed apart on purpose, because editing in your own audited desktop editor and editing in a tab open on a shared screen are not the same risk.

A session is issued, not a standing door

Opening a sandbox does not punch a permanent hole into the container. It mints a session: a single, signed grant tied to that sandbox, that mode, and you, that the platform can time out or revoke. A standing endpoint cannot tell you who is inside it right now, on whose authority, or for how much longer. A session answers all three, because of how it is bound. The four bounds that follow are those answers.

A session is bound on issue. The grant names the sandbox it is for, the mode it allows, and the person it was issued to, and it is signed, so a session altered after issue does not verify. A session minted for inspect cannot be talked into writing, and a session minted for one sandbox cannot be pointed at another.

A session is short-lived by clock, on three timers, not one:

1. It has to be opened soon after it is issued, within a tight first-open window, or it lapses unused. A link left sitting in a tab is not a way in tomorrow.
2. Once you open it, an idle timeout closes it after a stretch of no activity.
3. The credentials it issues to your editor carry their own short time-to-live, so even the keys in flight expire on their own.

A session is revocable now. You do not have to wait for a timeout. A session can be revoked the moment you are done with it, and once it is revoked the next attempt to attach is refused outright rather than quietly reconnecting. An editor that wandered off with an open tunnel cannot keep using it after the session is gone.

A session is on the record. Opening a sandbox in your IDE is an audited action, stamped with who opened it, against which sandbox, in which mode, and when; revoking it is recorded the same way. So the question a security owner actually asks, who looked inside this container and who could have changed it, is a row to read in the audit trail, not an investigation to open.

The browser editor and the desktop editor

The two paths suit two different moments, and most teams use both.

The browser editor is the zero-setup option. Click Inspect or Web Write and a new tab opens straight into an editor served from the sandbox's own service over a tunneled connection. Nothing to install, nothing to configure; it is there for the quick look or the one-line fix when reaching for your full IDE would be more ceremony than the task is worth.

The desktop editor is the full-fidelity option. A small companion app on your machine takes a short-lived ticket from the platform, resolves it for the SSH details, and launches VS Code Remote-SSH or JetBrains Gateway pointed at the container. From there it is your editor against /workspace: your extensions, your terminal, your muscle memory, on the sandbox's checkout. The ticket is what keeps this safe: short-lived and good for a single redemption, it gives the companion exactly enough to open the one session and nothing it can hold onto.

The companion app is a one-time install on your own machine, the piece that knows how to take the platform's ticket and hand it to VS Code or JetBrains. The first time you choose a desktop IDE, the platform hands off the ticket; if the companion is not installed yet, the handoff opens a page that tells you how to get it rather than failing in silence, so the desktop path is set up once and then stays out of your way. The browser modes need none of this, which is why Inspect and Web Write are the zero-setup way in.

A sandbox, opened and closed

Tom's overnight background task on the Export timeout bug came back for review, and the summary says it changed the streaming path, but he wants to see the files as the run left them before he trusts it. He opens the Sandboxes list, finds the task's container still up, and clicks Inspect. A tab opens into /workspace, read-only, and he reads the changed files in place, confirms the fix is where the summary said it was, and closes the session. Two minutes, no run, no risk of touching anything.

Later that day Priya is in the same situation on a different sandbox, but she spots a typo in a comment the agent left and would rather fix it than file it. Her profile allows browser write, so she clicks Web Write, fixes the line, saves, and closes the session. For the afternoon's real work, reworking a function across several files, she opens the sandbox in VS Code over SSH through the companion app and works in her own editor with her own tools, against the same live /workspace. When she is done, she closes the session, and the next attempt to reach that tunnel is refused. The container goes back to being the agent's.

Why opening a sandbox works this way

The obvious way to let someone into a container is to leave a door open: a standing SSH endpoint, a long-lived key, a tunnel that stays up. That is also the way that turns a convenience into a liability, because the door outlives the reason it was opened and nobody remembers to close it. Disco Parrot does the opposite. There is no standing door, only a session you open when you need it and that closes itself when you do not, and the act of opening one is recorded like any other access.

The two-mode split is the same instinct applied to writing. Reading the inside of a sandbox is cheap and common and should not require a decision; changing it is rarer and should. So inspect is the easy default and write is the deliberate step, gated for the browser by a policy your owners hold. The point is not to make editing hard. It is to make sure that when a person changes a container by hand, it is because they meant to, and that the trail shows it.

For a planner, opening a sandbox is how a review stops being a summary you take on faith and becomes something you can look at directly, in a tab, in two minutes, without learning anything new.

For an engineer, it is your own editor on the agent's workspace, with your extensions and keybindings, instead of a new tool to learn just to see what a run did: read it in the browser, fix one line there, or open VS Code or JetBrains over SSH when the task is real work, all against the same live /workspace.

For a lead, the handoff does not create a new standing way into your infrastructure. Every session is a bounded, revocable grant that times itself out, so giving the team easy access to look inside a sandbox does not leave a row of open doors behind it.

For the person who has to sign off on letting people into a running container, the controls are the ones that matter: read-only by default, write gated by profile policy, every session signed to one sandbox and one person, short-lived and revocable on demand, and every open and close recorded. Access is something that happens for a few minutes and is accounted for, not a key someone is holding.