:::meta author=Docs-Team updated=2026-09-03 tags=shell,terminal,files,restricted
:::
:::breadcrumb Docs > User Guide > Service Shell
:::
:::reading-time
:::
The Shell tab is a restricted, audited terminal into your service's container — plus a file tree and a built-in code editor. It is powerful enough for daily operations (inspect files, run migrations, check processes) and deliberately fenced: dangerous commands require confirmation, every command is logged, and access only exists for owners and share recipients with the shell rule. This page walks through opening a session, the terminal, the project browser, the editor, and the audit trail.
:::toc
:::
Opening a session
The tab starts with a single Open Shell button. Pressing it creates a session for you; if the service already has an active shell session — yours or another user's — a dialog explains who holds it and offers Terminate & open new shell. Taking over someone's session needs the replace permission, so a shared teammate's work is protected.
:::warning
The shell is restricted by a server-side command policy. Some commands are blocked outright, destructive ones require explicit confirmation, and everything you run is recorded in the shell activity log with your username, the command, and its exit code.
:::
The terminal
The shell view opens as a dark, IDE-style frame with a tab strip (Shell plus any open file tabs). The command line is a prompt at your current working directory with:
• Command history — press the up and down arrows to walk through previous commands (up to 100, merged with the server's recent history).
• Completion — Tab (or Ctrl+Space) opens a completion popup for commands and paths, navigable with the arrow keys.
• Clearing — the clear command or Ctrl+L wipes the view.
• File shortcuts — running nano, vi, or vim on a file opens it in the built-in editor tab instead of a terminal editor.
Interactive programs run through a real PTY rendered with xterm.js — the hint line explains the essentials: Ctrl+C interrupts, Ctrl+D exits, and typed keys go directly to the process. Password prompts are detected automatically and your input stays invisible.
:::tip
Toggle the dry-run chip before running a risky command: the shell then prints a numbered plan of what the command would do — with [destructive] markers — without executing anything.
:::
When a command would change application state, the server answers with a confirmation dialog — "Confirm command" showing the exact command in a code box — and only Run executes it. Friendly error labels cover the common refusals: permission denied, blocked by security policy, command not found, timed out, resource limit exceeded, and similar.
The project browser
The PROJECT sidebar is your container's file tree. Its toolbar has New file, New folder, and refresh; a breadcrumb shows the current path. Rows carry writability badges — RO and RW, or RW · LOCKED while the platform checks the real state — and double-clicking a directory descends into it. The context menu (right-click) offers New file here, Edit, Open directory, Rename, Copy path, and Delete with a per-item confirmation.
The terminal toolbar complements the browser: a sidebar toggle (Hide project / Show project), the working-directory chip (or Disconnected), the dry-run toggle, and three dialogs:
| Button | Contents |
| --- | --- |
| Snippets | Platform-aware command snippets — Django manage.py check and migrate, Laravel route:list, version checks, and generic inspection commands |
| Env | The container's environment with secret values masked |
| Audit | The shell activity log — see below |