Skip to content
MelMel
Terminal > Getting started

Supported shells

Which shells Mel runs and how your shell environment is loaded.

Mel doesn't replace your shell — it runs it. Your aliases, functions, prompt tooling, and history keep working, because every command executes inside the shell you already use.

Which shell runs

  • macOS and Linux: Mel uses $SHELL — whatever your login shell is set to (bash, zsh, fish, …). Commands run through it, so shell-specific syntax behaves exactly as it does in any other terminal.
  • Windows: Mel uses cmd.exe.

Commands run in a real PTY sized to match the visible pane, so column-oriented programs like ls lay out correctly, and full-screen TUI programs (editors, top, CLI coding agents, ssh sessions) get a proper terminal with TERM=xterm-256color.

Environment hydration

There's a subtle problem every GUI terminal has to solve: when you launch an app from a desktop launcher or dock instead of another terminal, it inherits a minimal environment. Anything your shell rc files set up — nvm and pyenv shims, PATH additions, exported keys, CLIs like claude or codex installed via a shell installer — would be invisible, and you'd hit "command not found" for tools that work fine in your usual terminal.

Mel fixes this with login-shell environment hydration: once at startup, on a background thread, Mel runs your $SHELL as a login + interactive shell ($SHELL -l -i -c env), captures the resulting environment, and applies it to every command it runs. So no matter how Mel was launched, your commands see the same environment a real login terminal would.

A few properties of this design:

  • It runs once per app launch and is cached; there's no per-command overhead.
  • The capture has a timeout, so a slow or misbehaving rc file can't hang startup — Mel falls back to the inherited environment.
  • Explicit terminal variables (like TERM) are still set by Mel after hydration.

If you change your rc files (say, you add a PATH entry to ~/.zshrc), restart Mel to pick it up — hydration happens at launch.

What follows your shell, what doesn't

  • cd in the prompt moves the pane's tracked working directory (only when the command succeeds — a failed cd never moves you), and everything downstream follows: block headers, the directory chip, chip detection, the agent's working directory.
  • Ghost autocomplete reads your real shell history (~/.zsh_history / ~/.bash_history) alongside the current session.
  • Runtime chips integrate with your version managers directly: the Node chip lists installs from ~/.nvm, the Rust chip lists toolchains from ~/.rustup, and picking one runs the visible nvm use / rustup default command.
  • Per-pane environment tweaks (a Node version override, or a Drive environment set you loaded) apply on top of the hydrated environment for that pane only.

Related