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 as the terminal UI layer (native macOS windows/tabs, clean config)
- tmux as 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
This is the harmless terminal holy war:
“Why not just use terminal tabs?”
Because tabs are 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
- It supports detach/attach and long-running sessions
- It’s keyboard-first and consistent across machines
- It encourages repeatable structure: one session per project, windows per task
To be clear: tabs are great. I still use Ghostty tabs - but as a UI feature, not as my persistence strategy.
What I wanted from my setup
1) Persistence without friction
I want to reopen my 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.
And tmux should not hijack every shell I open.
So 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.
So I stored everything in a repo:
- 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
Instead of thinking “where did I run that command?”, the structure stays consistent.
Easy migration
New machine? Clone 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: https://github.com/Gunpy/ghostty_tmux.git
Who should try this
This approach is 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,
- and 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,
- or separate sessions for local vs remote?
Top comments (0)