Skip to content

Terminal Panel

import { Aside } from ‘@astrojs/starlight/components’;

The Terminal panel runs a real PTY (pseudoterminal) session — not a simulation, not a sandbox, not a WebSocket-to-SSH bridge. It’s your actual shell, with everything that implies.

  • Your shell — zsh, bash, fish, or any POSIX-compatible shell
  • Your config.zshrc, .bashrc, aliases, functions, all loaded
  • Your tools — nvm, conda, pyenv, rbenv, homebrew — everything works
  • Full color — 256-color and true color (24-bit) support
  • Multiple sessions — each panel runs an independent shell

Under the hood, the terminal panel uses xterm.js for rendering and node-pty for the PTY backend. This is the same approach used by VS Code’s integrated terminal, but in a dedicated panel that can be split, resized, and arranged alongside other tools.

Each terminal panel tracks its working directory. The File Navigator can sync to the active terminal’s directory, so your file tree always shows what’s relevant.

When you cd into a directory, the terminal panel’s title updates to reflect the current path. If you’ve named the panel, the name takes priority.

You can have as many terminal panels as you need. Common patterns:

PanelPurpose
Terminal 1Dev server (npm run dev, flask run)
Terminal 2Gee-Code session
Terminal 3Git operations
Terminal 4Tests and builds

Each runs independently. A long-running process in one panel doesn’t block others.

Terminal sessions persist across workspace saves. When you close and reopen The Terminal, your shell sessions restore to the same working directory. Running processes (like dev servers) will need to be restarted.

  • Clicking anywhere in a terminal panel makes that panel active and focuses the shell input.
  • After Space/layout visibility changes, terminal fitting is deferred to preserve scroll position and avoid prompt truncation.
  • If a tool emits terminal status messages, those states can be surfaced in the Spaces panel as status chips.