Desktop, terminal & logs
The live surfaces of a sandbox — a streamed desktop, a terminal you can type into, and dev-server logs.
A sandbox is a full Linux environment, and you're not limited to reading about it after the fact. While agents work, you can watch the machine and use it yourself.
The streamed desktop
The sandbox runs a desktop with an in-VM browser, streamed to you live. Because it's a real browser in a real environment, logins, OAuth redirects, and cookies all work normally — no headless workarounds, no mocking your auth provider.
Two things happen here. You can drive the browser yourself to click around your app, and you can watch a UI driver sub-agent operate it in real time — the same run that produces video proof of a feature working.
The terminal
A terminal streams into the panel, and you can type into it. It's the same shell the agents use, in the same working tree, so what you see is the state they're acting on: run a test, check a process, inspect a file the agent just wrote.
Dev-server logs
Your app's dev-server output streams live, and during project setup the build console streams alongside it. This is usually the fastest way to understand a failure: a stack trace in the log beats asking an agent to guess why a page is blank.
| Surface | What it shows |
|---|---|
| Desktop | The in-VM browser and anything with a GUI, streamed. |
| Terminal | A shell in the thread's working tree, interactive. |
| Dev-server logs | Live app output, plus the build console during setup. |
The dev server is always up
The dev server starts automatically when the sandbox boots and stays up, using the project's run config. So the preview you're looking at is the thread's live working tree — not a build from earlier, and not main. An agent edits a file, and the running app reflects it.
That's also why these surfaces are worth checking during a run rather than only afterwards: the app in front of you is the change in progress.
Keeping the environment awake
Sandboxes pause when idle to save resources and resume on demand. That's what makes it reasonable to keep many threads open at once.
Idling would be annoying if it happened mid-inspection, so it doesn't: while a desktop, terminal, or log view is on screen, a keepalive heartbeat keeps the environment from being paused out from under you. Watching counts as activity.
Using them well
- A blank preview? Read the dev-server log before asking the agent anything — you'll usually have the answer in a line or two.
- Need to see a flow, not a diff? Watch the desktop while a UI driver runs it, or drive it yourself.
- Want to check a command an agent claims it ran? Run it in the terminal; you're in the same tree, so the result is comparable.
- Environment change not taking effect? A running dev server keeps its old environment until restarted — see Secrets & environment.
For the wider layout these surfaces sit in, see the workspace tour.