# Desktop, terminal & logs

> The live surfaces of a sandbox — a streamed desktop, a terminal you can type into, and dev-server logs.

A [sandbox](https://darting.dev/docs/isolated-sandboxes/) 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](https://darting.dev/docs/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](https://darting.dev/docs/projects-and-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](https://darting.dev/docs/run-config-and-snapshots/). 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](https://darting.dev/docs/secrets-and-environment/).

For the wider layout these surfaces sit in, see [the workspace tour](https://darting.dev/docs/workspace-tour/).