A lot of terminal setups look productive… until you restart your machine

Source: Dev.to

Introduction

If you regularly run multiple dev servers, keep SSH sessions open, tail logs, or bounce between projects, you know the routine:

• reopen terminal windows
• reconnect to hosts
• recreate splits
• re‑run commands
• repeat

I didn’t want “cool terminal aesthetics”. I wanted a workspace that survives normal life.

So I built a simple, repeatable workflow on macOS:

• Ghostty – the terminal UI layer (native macOS windows/tabs, clean config)
• tmux – the state layer (sessions/windows/panes, detach/attach, persistence)

plus one decision that keeps the setup practical: tmux auto‑starts only in Ghostty – Terminal.app stays clean.

The small controversy: tabs aren’t a workspace

“Why not just use terminal tabs?”

Tabs are merely a view; they don’t encode recovery. Your layout and runtime context still live in your head.

tmux is different. It has a stable model: session → windows → panes.

• Supports detach/attach and long‑running sessions
• Keyboard‑first and consistent across machines
• Encourages repeatable structure: one session per project, windows per task

Tabs are great – I still use Ghostty tabs – but only as a UI feature, not as my persistence strategy.

What I wanted from my setup

1) Persistence without friction

Reopen the terminal and continue:

• same project context
• same commands running
• same layout

2) Separation of concerns

• A terminal emulator should not decide how I manage sessions.
• tmux should not hijack every shell I open.

Thus I made it explicit:

• Ghostty = development workspace
• Terminal.app = default system shell

3) Reproducibility

A “good setup” that can’t be recreated is just a lucky accident. All configuration lives in a repository:

• Ghostty config
• tmux config (+ TPM plugins)
• a Zsh snippet to autostart tmux only in Ghostty
• documentation and usage notes

What this gives me in practice

• Instant “back to work” – Open Ghostty → attach to main → everything is already there.
• A workflow that matches real development – one session per project, windows for backend/logs/infra, panes for quick splits.
• Less mental overhead – the structure stays consistent, so you don’t wonder “where did I run that command?”.
• Easy migration – new machine? Clone the repo, copy configs, install tmux, done.

What’s in the repository

• config/ghostty/config – Ghostty config (fonts, keybindings, Option‑as‑Alt)
• config/tmux/tmux.conf – tmux config (window/pane bindings, copy‑mode, plugins)
• config/zsh/tmux-ghostty.zsh – auto‑start tmux only in Ghostty
• A full README with installation steps and daily usage (sessions/windows/panes)

Repo:

Who should try this

Especially useful if you:

• run multiple dev servers and watchers daily
• keep SSH sessions open
• work across multiple environments
• want persistence without turning tmux into a global requirement

If you’re a “no tmux, only tabs” person – that’s fair. But if you’ve ever rebuilt the same terminal state three times in a week, tmux starts to look less like a hobby and more like ergonomics.

Closing

This setup is intentionally boring:

• minimal moving parts
• predictable behavior
• easy to reproduce

If you try it, I’d love to hear how you organize your workspace:

• one session per project
• one session for everything
• separate sessions for local vs remote

Repo: