tmux
Terminal multiplexer for managing multiple sessions
3 members list tmux, up 3 in the last 12 weeks, data as of 10 September 2026
Used alongside tmux
Tools that members list in the same stack as tmux.
Members who list tmux in their Stack, by week.
Hacker News mentions mentions: 2 mentions (2009) to 250 mentions (2026)
Imported from Hacker News mentions
Stack Exchange data explorer questions asked: 1 questions (2009) to 1 questions (2025)
Imported from Stack Exchange data explorer
Wikipedia pageviews pageviews: 6,010 views (2015) to 4,087 views (2026)
Imported from Wikipedia pageviews
Moves that use tmux
Before I started doing this, I'd either have a pile of detached sessions scattered across my machine with no memory of what was running in each one, or I'd try to cram multiple projects into a single session and lose track of which window belonged to where. Terminal scrollback would evaporate whenever my laptop slept, and context switching meant either killing running processes or leaving them orphaned and resource-hungry in the background. What changed is that I now create each project's session with a predictable structure. Editor window, server window, tests window. Always in that order. When I come back to a project after days away, I run `tmux attach-session -t projectname` and everything is exactly where I left it. The scrollback persists because the processes aren't dying. I can actually see what broke three hours ago because I still have the terminal history. The concrete implementation is a small shell function that creates a session with `tmux new-session -d -s $projectname -x 120 -y 40`, then splits windows with `tmux new-window -t $projectname` and names them with `tmux rename-window -t $projectname:0 editor`. Zsh and Neovim run in window zero, the dev server or build process lives in window one, and automated tests run in window two. One keybinding to cycle between them. The honest limitation is that this breaks down if a project genuinely needs more than three persistent processes, or if you're debugging something that requires seeing multiple logs simultaneously. For those cases I sometimes add a fourth window, but I've found that creeping complexity usually means I should split the workflow differently. It works best when your development process is actually that simple.