Stackness
t

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.

Usage on Stackness
3membersup 3 in the last 12 weeks

Members who list tmux in their Stack, by week.

History
Collected from public datasets outside Stackness, not from stacks on this site. Each series is scaled to its own peak because the units do not compare. Data sources
Mentions, monthly

Hacker News mentions mentions: 2 mentions (2009) to 250 mentions (2026)

20092013201820222026

Imported from Hacker News mentions

Questions asked, monthly

Stack Exchange data explorer questions asked: 1 questions (2009) to 1 questions (2025)

20092014201820212025

Imported from Stack Exchange data explorer

Pageviews, monthly

Wikipedia pageviews pageviews: 6,010 views (2015) to 4,087 views (2026)

20152018202120232026

Imported from Wikipedia pageviews

A
Alex Mueller

@alex_rust

R
Ruby Sandoval

@gen_ruby_fan

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.

44
See all moves that use tmux