tmux attach session: tmux a, -d, and the resize problem

tmux attach -t name reconnects your current terminal to the session called name. tmux a is shorthand for the same command and, with no -t, attaches to the most recently used session. The part that actually causes confusion isn't attaching — it's what happens when two terminals attach to the same session at different sizes, which is covered below. If sessions, windows and panes aren't distinct in your head yet, the tmux tutorial sets that model up first.

attach vs attach-session vs tmux a#

These are three ways to type the same command — all covered alongside the rest of tmux's session commands in tmux commands:

There's no functional difference between them. tmux a with no target is the one worth building a muscle-memory habit around — it's the fastest way back into whatever you were doing last.

Attaching by name or index#

-t takes either the session name or its index:

tmux ls (alias for list-sessions) before you attach is worth the habit — it's a two-second check that saves you attaching to the wrong session, and it's the only reliable way to see a session name you don't remember setting. See tmux new session for why naming sessions at creation time makes this list actually readable.

-d: detach other clients before you connect#

If a session is already attached somewhere else — another terminal on the same machine, or a second SSH connection — attaching again doesn't kick that client out by default. Both clients stay attached, sharing the same view. -d changes that:

tmux attach -d -t work

This detaches every other client first, then attaches yours. It's the right call any time you left a session open on another machine or terminal and don't want to fight over which client's window size wins — which is the actual problem, covered next.

The size problem: two clients, two terminal sizes#

This is the single most common source of "tmux is being weird" reports, and it isn't a bug — it's tmux doing exactly what it's configured to do. A tmux window (not the terminal emulator, the tmux window) has one size. If two clients are attached to the same session and looking at the same window, and their terminals are different sizes, tmux has to pick one size for the window. By default it picks the smallest.

That's the window-size option, and its default is latest in modern tmux, but the practical effect people hit is still governed by aggressive-resize. Both options are described in full in the tmux man page, which is worth checking against your own tmux -V — the defaults changed between releases:

The practical version: if you attach from a small terminal (say, a phone SSH client or a narrow split) while a wide session is already attached elsewhere, everyone's view can shrink to fit yours — even the person who isn't looking at that window. aggressive-resize on scopes that to only the clients actually viewing the window in question, which is what most people actually want:

setw -g aggressive-resize on

If you don't want a second attach affecting the layout at all, use -d to detach the other client instead of sharing the view, or attach with -r for a read-only client that observes without contributing to the size negotiation.

Attaching over SSH#

Nothing about tmux attach changes over SSH — it's the same command, run on the remote machine, not your laptop. tmux over SSH goes into the surrounding setup; this is just the attach half of it:

The session lives on deploy-box's tmux server, not on your laptop, so closing the SSH connection (network drop, laptop sleep, closing the terminal) detaches you but leaves the session running exactly like a manual prefix d would. Reconnect and tmux a gets you back to where you left off. That's the entire reason to run long jobs inside tmux over SSH in the first place — an unstable connection stops mattering. If the reconnecting itself is the annoyance, Mosh solves the other half of the problem: it keeps the remote shell alive across roaming and sleep, and people commonly run tmux inside it rather than instead of it.

"No sessions" and "can't find session" errors#

tmux gives you two different messages depending on what's actually missing:

no sessions means the tmux server isn't running at all — nothing has been created since boot, or tmux kill-server was run. can't find session: bar means the server is running fine but no session by that name exists — check tmux ls for the actual name, or create it with tmux new -s bar. Either way, tmux new-session -A -s bar sidesteps both errors: it attaches if bar exists and creates it if it doesn't.

Checking a session when you aren't at a terminal at all#

tmux attach assumes you have a terminal to attach from — SSH client, laptop, phone terminal app. Getting a usable one onto a phone is its own exercise, which tmux from a phone works through. The case none of them cover is wanting to glance at a session's output from a plain browser, with no SSH client installed. That's the specific gap mtmux fills: it serves the tmux session you already have to a browser tab, end-to-end encrypted, with nothing to port-forward and no SSH key on the device doing the looking — and without changing how attach itself works. The feature overview is the short version, and the session reference covers how attaching and detaching map onto the browser client.