# Web Terminal (/docs/web-terminal)

Daytona provides a browser-based web terminal for your sandboxes. Run commands, view files, and debug from your browser without installing local tools.

<WebTerminalVisual />

## Use cases [#use-cases]

The web terminal is used when a person needs a shell in a sandbox from the browser, with no local tools.

- **Command execution.** A person runs shell commands in the sandbox from the sandbox details page. On a Linux sandbox whose desktop is neither starting nor ready, the **Terminal** tab opens by default, so opening the sandbox lands in a shell. The shell is the login shell of the sandbox user, or the first of bash, zsh, and sh found on the PATH.

- **File management.** A person moves through the file system and views and edits files. **Open terminal here** in the **Files** tab starts a shell in the selected folder. Members without the sandbox write permission do not see the **Files** tab.

- **Full-screen programs.** Programs such as `top`, `vim`, and `htop` work as in a local terminal. Resizing the browser window resizes the terminal in the sandbox. Each session starts at 80x24 and is resized to fit the browser viewport right away.

- **Debugging.** A person reads logs, checks processes, and finds the cause of a problem in a running sandbox. The terminal works only while the sandbox is running, so start a stopped sandbox first. Stopping or restarting the sandbox ends every shell, and the **Terminal** tab starts a fresh session once the sandbox runs again.

- **Shells shared with code.** Each session is a PTY process, so the SDK, the CLI, or the API can attach to the same shell. The browser and the attached client share keystrokes and output. A client finds a session by its name, `web-term-` followed by a number.

## Access from Dashboard [#access-from-dashboard]

The web terminal is built into the sandbox details page of the [Daytona Dashboard ↗](https://app.daytona.com/dashboard/sandboxes).

1. Go to [Daytona Sandboxes ↗](https://app.daytona.com/dashboard/sandboxes)
2. Locate the running sandbox you want to access
3. Click **Open terminal** in the sandbox row, or the sandbox's **Terminal** tab

The **Terminal** tab is the default tab of the sandbox details page for Linux sandboxes whose desktop is not starting or ready, so opening such a sandbox lands you directly in a shell. macOS and Windows sandboxes, and Linux sandboxes with a starting or ready desktop, open on the **Desktop** tab. The tab also opens directly from a sandbox details URL whose tab query parameter is set to terminal. The web terminal is available only for sandboxes in the running state. If your sandbox is stopped, start it before attempting to access the terminal.

### Multiple sessions [#multiple-sessions]

Each terminal tab is an interactive shell running as a [PTY process](/docs/pty) inside the sandbox. Opening the **Terminal** tab on a sandbox with no sessions creates the first one automatically. You can:

- Open additional sessions with the **+** button and switch between them
- Drag tabs to reorder them, or right-click a tab to close, close others, or pin it
- Close a session to stop its shell process

Pinned tabs stay fixed on the left of the tab strip, cannot be dragged, and are skipped by **Close others**. Tab order, pinned tabs, and the active tab are remembered in your browser per sandbox, so reopening the sandbox restores the same layout.

Sessions stay alive while the sandbox runs, so reloading the page reconnects to your existing shells. A shell that exits on its own, for example after the exit command, closes its tab within seconds.

### Open a terminal in a directory [#open-a-terminal-in-a-directory]

From the **Files** tab, open the actions menu (**⋯**) of a folder and choose **Open terminal here** to start a new terminal session with that directory as its working directory.

## Shell [#shell]

Each session starts an interactive shell with an initial size of 80x24 that is immediately resized to fit the browser viewport. The shell is the login shell of the sandbox user, falling back to bash, zsh, then sh from the PATH.

Full-screen programs such as top, vim, or htop work as in a local terminal. Resizing the browser window or the side panel resizes the remote PTY.

## Sessions and scrollback [#sessions-and-scrollback]

Web terminal sessions are regular PTY processes on the sandbox, named with a web-term prefix and a number that sets the tab title. Only web-term processes appear as tabs; the web terminal neither shows nor touches PTY sessions started through the SDK or API.

Sessions are ordinary processes, so you can list and attach to them programmatically. SDK and browser clients attached at once share one shell, including keystrokes and output.

<Tabs syncKey="language">
<TabItem label="Python" icon="seti:python">

```python
processes = sandbox.process.list(kind="pty", state="running")
session = next((info for info in processes.items if info.name and info.name.startswith("web-term-")), None)
if session is None:
    raise RuntimeError("no web terminal session")
print(f"{session.name}: {session.id} (cwd {session.cwd})")

# Attach to the web terminal session by its process id
handle = sandbox.pty.connect(session.id)
handle.write_stdin('echo "Hello from the SDK"\n')
```

</TabItem>
<TabItem label="TypeScript" icon="seti:typescript">

```typescript
const processes = await sandbox.process.list({ kind: 'pty', state: 'running' })
const session = processes.items.find((info) => info.name?.startsWith('web-term-'))
if (!session) throw new Error('no web terminal session')
console.log(`${session.name}: ${session.id} (cwd ${session.cwd})`)

// Attach to the web terminal session by its process id
const handle = sandbox.pty.connect(session.id)
const connection = await handle.attach()
connection.write('echo "Hello from the SDK"\n')
```

<Callout type="note" title="Notes">
- The request requires the `write:sandboxes` permission.
- `attach` needs a global `WebSocket` class.
</Callout>

</TabItem>
<TabItem label="CLI" icon="seti:shell">

```bash
# List running PTY processes; web terminal sessions are named web-term-<n>
daytona sandbox process list {sandboxId} --kind pty --state running

# A live session can also be fetched by name
daytona sandbox process get {sandboxId} web-term-1

# Attach to a web terminal session
daytona sandbox process attach {sandboxId} web-term-1
```

</TabItem>
<TabItem label="API" icon="seti:json">

```bash
# List running PTY processes; web terminal sessions are named web-term-<n>
curl '{toolboxProxyUrl}/{sandboxId}/processes?kind=pty&state=running' \
  --header 'Authorization: Bearer <API_KEY>'

# A live session can also be fetched by name
curl '{toolboxProxyUrl}/{sandboxId}/processes/web-term-1' \
  --header 'Authorization: Bearer <API_KEY>'
```

<Callout type="note" title="Notes">
- The request requires the `write:sandboxes` permission.
- `{toolboxProxyUrl}` is the `toolbox_proxy_url` field of the [sandbox](/docs/sandboxes#get-a-sandbox).
</Callout>

</TabItem>
</Tabs>

## Security [#security]

Terminal access is restricted to authenticated members of your [organization](/docs/organizations) whose [project API key](/docs/api-keys) holds the sandbox write permission. Members without this permission do not see the Terminal, Files, Desktop, or SSH tabs, and the terminal icon is hidden in the sandbox list. The terminal is served through the toolbox proxy, which authenticates every request with a short-lived access token scoped to that sandbox; making a [preview endpoint](/docs/preview) public does not expose the terminal.

<Callout type="caution" title="Warning">
The web terminal provides full shell access to your sandbox. Grant the sandbox write permission only to members who should be able to run arbitrary commands in your sandboxes.
</Callout>