Tmux persists because the server owns the session, not your terminal
Tmux keeps sessions alive by moving state into a persistent server process. Clients attach via a Unix socket, so detaching preserves programs, layout and scrollback for later reattachment.
25 Aug 2026, 02:56 UTC

SSH drops, laptop sleeps, or you switch machines and the long-running build, log tail and REPL you had open vanish with the client. The useful takeaway is that tmux solves this by moving session state out of the terminal client and into a persistent server process. Clients are thin viewers that attach to a Unix domain socket; the server keeps sessions, windows, panes, programs, environment and scrollback alive while clients come and go.
Server owns state, clients are disposable
In tmux a single server process owns all sessions. A session is a collection of windows, each window is a collection of panes, and each pane runs a pseudo-terminal. Clients connect to the server via a socket, usually under /tmp or $XDG_RUNTIME_DIR, and render what the server sends.
That decoupling means detaching a client with prefix+d does not stop anything. The server continues to run the programs, keep their stdout/stderr buffers and preserve pane layout in memory. Reattaching later with tmux attach-session -t name reconnects a new client to the same server state.
Verify the separation locally. Run tmux -V to note the major version, because option names and defaults differ between tmux 2.x and 3.x. Then start a named session from a shell where you have permission to create the socket:
tmux new-session -s demoFrom another shell run tmux list-sessions. The session should be listed even though no client is attached to it from that shell. Detach with prefix+d and reattach with tmux attach-session -t demo to confirm the pane contents and layout are unchanged.
Configuration is a server-wide decision
Configuration is loaded from tmux.conf when the server starts and applies globally to all clients that connect to that server. That makes choices like prefix key, mouse mode, default-terminal and key bindings consistent for everyone sharing the server.
Inspect the running server’s effective options with:
tmux show-options -gand key bindings with:
tmux show-keysChanges made to the running server with tmux set-option are in-memory only and lost when the server exits. Persistent changes belong in tmux.conf and require restarting the server.
Socket location and permissions control who can attach. Check the socket path for the current server:
tmux display-message -p '#{socket_path}'Inspect file permissions on that socket. An overly permissive socket allows other users on the host to attach to and control your sessions, exposing running processes and input. Use a user-owned socket directory and avoid world-writable paths.
A reusable layout for parallel work
A practical pattern is a named session with a stable pane layout for a task, then detach and reattach across machines.
Create the session detached so you can attach when ready:
tmux new-session -d -s deployFrom that session create a vertical split for logs and a horizontal split for an editor and shell. Pane commands are sent to the server, which stores the layout:
tmux select-window -t deploy:0
tmux split-window -v -t deploy:0.0
tmux split-window -h -t deploy:0.1Attach to work:
tmux attach-session -t deployWhen you are done, prefix+d detaches. The server keeps the programs running and the scrollback buffers. Later tmux attach-session -t deploy resumes exactly as left.
Trade-offs to watch
Because state lives in the server, resource use accumulates in the server process. Large scrollback history and many active panes increase server memory use. Plan scrollback limits in tmux.conf and prune unused sessions with tmux kill-session -t name.
Sharing is built in via the socket. Multiple users can attach to the same session, which enables pair debugging and handoff, but also means any attached client can send input to any pane. Control access via socket permissions and consider separate servers for sensitive work.
Version differences matter for defaults. Verify your version first and test option names with tmux show-options before relying on them in scripts.
Use the server model deliberately: keep long-running work in named sessions, detach instead of closing terminals, and treat tmux.conf as server policy rather than per-client preference.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.