Building a Faster Terminal: Starship, Shells, and tmux

Building a Faster Terminal: Starship, Shells, and tmux

By Pashalis LaoutarisUpdated: Category: Developer Tools8 min read

I wrote about my daily development setup recently and mentioned running Starship as my prompt. A few people asked for more detail on the actual terminal setup behind it. So this is that spin-off: the shell, the prompt, and the session manager, and why each piece is worth the ten minutes it takes to configure.

None of this is about chasing the trendiest terminal emulator. It’s about a setup that starts fast, shows you what you need at a glance, and doesn’t get in your way.

Table of Contents

  1. What This Setup Actually Solves
  2. Starship: One Prompt, Every Shell
  3. Picking a Shell: Zsh vs Fish
  4. tmux: Sessions That Survive
  5. Putting It All Together
  6. Frequently Asked Questions (FAQ)
  7. Conclusion
  8. References

1. What This Setup Actually Solves

Three separate problems, each solved by a different tool:

  • The prompt doesn’t tell you enough. A default shell prompt shows your current directory and not much else. You end up running git status and git branch constantly, just to know what state you’re in.
  • Switching shells means relearning your prompt. Say you configure a custom prompt in Bash, then need Zsh for a specific plugin. You’re often starting from scratch.
  • Terminal sessions die when the connection does. Close your laptop lid or lose an SSH connection, and every running process in that terminal window goes with it. Unless something is keeping the session alive independently.

Starship solves the first two. tmux solves the third. The shell you pick underneath them mostly comes down to personal taste and plugin ecosystem.

2. Starship: One Prompt, Every Shell

Starship is a cross-shell prompt written in Rust. The pitch is simple: one starship.toml file configures an identical prompt (same modules, same colors, same behavior) across Bash, Zsh, Fish, PowerShell, and Nushell. Switch shells, and your prompt doesn’t change.

It’s also fast. Starship typically renders in the 5-15 millisecond range, occasionally more in a very large Git repo when a module has extra work to do. That matters more than it sounds like it should. A slow prompt adds a barely perceptible delay to every single command you run, all day. It compounds into a real feeling of sluggishness over a full session. Fast enough, in practice, that prompt latency stops being something you notice at all.

Installation:

curl -sS https://starship.rs/install.sh | sh

Enable it per shell. For Zsh, add this to ~/.zshrc:

eval "$(starship init zsh)"

For Fish, add this to ~/.config/fish/config.fish:

starship init fish | source

A minimal starship.toml showing your directory, Git branch, Git status, and a language runtime version when relevant:

[directory]
truncation_length = 3
truncate_to_repo = true

[git_branch]
symbol = " "

[git_status]
conflicted = "="
ahead = "⇡${count}"
behind = "⇣${count}"

[nodejs]
format = "via [ $version](bold green) "

Drop that in ~/.config/starship.toml, and every shell you’ve enabled Starship in picks it up immediately. No restart required.

One note on fonts: those little symbols (the branch glyph, the arrows) need a Nerd Font, installed and selected in your terminal emulator. Without one, they render as boxes or question marks. That’s the single most common “Starship looks broken” complaint. Install a Nerd Font first, and this stops being an issue.

3. Picking a Shell: Zsh vs Fish

Starship makes this choice lower-stakes than it used to be, since your prompt configuration carries over regardless. What’s left to actually compare is the shell’s own scripting behavior and plugin ecosystem.

Zsh is POSIX-compatible. That means most Bash scripts and tutorials written for Linux and macOS environments work with little to no modification. It has the larger plugin ecosystem (Oh My Zsh, zsh-autosuggestions, zsh-syntax-highlighting), and it’s the default shell on macOS, so you’re not fighting the platform.

Fish trades POSIX compatibility for sane defaults out of the box: syntax highlighting, autosuggestions based on history, and tab completion, all working immediately with zero configuration. The tradeoff is that Fish’s scripting syntax isn’t POSIX. Copy-pasted Bash snippets from documentation or Stack Overflow often need small adjustments before they’ll run.

If you’re following along with tutorials that assume Bash, or you SSH into a lot of servers where Fish isn’t installed, Zsh is the pragmatic default. If you mostly work in one interactive terminal and want the best experience with the least configuration, Fish is worth trying.

4. tmux: Sessions That Survive

tmux is a terminal multiplexer. It runs your shell sessions inside a persistent process on the machine, and your actual terminal window just attaches to that process as a viewer. Close the terminal, lose the SSH connection, or reboot your local machine, and the tmux session on the remote machine keeps running exactly where you left it.

Basic workflow:

tmux new -s work        # start a new named session
# ... do work, run a long process ...
# Ctrl+b, d              # detach, leaving it running
tmux attach -t work      # reattach later, from anywhere

Ctrl+b is just tmux’s default prefix key, pressed before every command shown above. It’s remappable in ~/.tmux.conf if you’d rather use something else, but the default works fine to start with.

This matters most for anything long-running on a remote server: a build that takes 20 minutes, a database migration, a script you’re monitoring. Without tmux (or an equivalent like screen), losing your SSH connection kills the process. With it, the process keeps running in the background session, and you just reconnect to watch it finish.

Splitting panes is the other reason people adopt tmux even on a local machine:

tmux split-window -h    # split vertically (side by side)
tmux split-window -v    # split horizontally (stacked)

One pane for your editor’s terminal, one for a running dev server, one for git commands, all inside a single terminal window. All switchable with a keybinding, instead of alt-tabbing between separate terminal apps.

Important detail: Starship works correctly inside tmux without any special configuration. That’s because Starship customizes the shell’s prompt, not the terminal emulator itself. tmux just displays whatever the shell running inside it renders, so the two tools don’t need to know about each other at all.

5. Putting It All Together

A complete, minimal setup looks like this:

  1. Install Starship, enable it in your shell’s rc file.
  2. Pick Zsh (for compatibility) or Fish (for zero-config ergonomics) as your daily shell.
  3. Install tmux, and start using named sessions (tmux new -s <project-name>) for anything you run on a remote server.
  4. Drop one starship.toml in your dotfiles repo, so the same prompt config follows you to every machine you set up. Symlink it into place (ln -s ~/dotfiles/starship.toml ~/.config/starship.toml) on each new machine, and you’re done. No copy-pasting required.

That’s the whole stack. No terminal emulator swap required, though a GPU-accelerated terminal emulator on top of this (several exist as of 2026) can shave a little more latency off rendering, if you’re chasing every last millisecond.

6. Frequently Asked Questions (FAQ)

Does Starship slow down my shell startup?

No, the opposite. Starship is specifically built to render in roughly 5-15ms, which is faster than most heavyweight shell frameworks like Oh My Zsh with a large plugin set.

Can I use Starship on Windows?

Yes. It supports PowerShell directly, and works identically inside WSL, if you’re running a Linux shell like Zsh or Fish there instead.

Do I need tmux if I only work locally and never SSH anywhere?

Less critical, but still useful for the pane-splitting workflow alone: multiple terminal views inside one window, switchable with keybindings, without needing separate terminal app windows.

Will my existing Bash scripts work if I switch to Fish?

Not always, since Fish deliberately isn’t POSIX-compliant. Simple scripts usually port with minor edits. Anything relying on Bash-specific syntax ([[ ]] conditionals, certain parameter expansions) needs to be rewritten in Fish’s own syntax, or run explicitly via bash script.sh instead of sourcing it.

What happens to a tmux session if the server reboots?

It’s gone. tmux keeps sessions alive across a dropped connection, not across the host machine actually restarting. For that level of persistence, you’d need the process itself managed by something like systemd or a process supervisor, with tmux (or nothing) layered on top just for interactive access.

7. Conclusion

This isn’t a large investment for what it returns. Starship takes ten minutes to install and configure once, and then every shell you touch shows you the same useful, fast prompt. Picking Zsh or Fish is mostly about whether you value POSIX compatibility or zero-config ergonomics more. tmux is the one piece that actually changes how you work with remote servers. It turns “my SSH connection dropped and killed my build” into a problem that simply doesn’t happen anymore.

Set it up once, put the config in a dotfiles repo, and it follows you to every new machine from then on.

8. References

Back to All Posts
Share this post:
Share on X
Share on LinkedIn
Share on Reddit
Share on Facebook
Copy Link
Copied!