Sharing a tmux session is a fantastic way to pair program remotely, but the magic isn’t in the sharing itself, it’s in how it makes remote collaboration feel as seamless as sitting side-by-side.
Let’s see it in action. Imagine Alice and Bob are pair programming on a Go project. Alice starts a tmux session on her machine:
tmux new-session -s pair-programming
She then splits her pane vertically and starts a Go server in one pane and opens her vim editor in the other:
# In the first pane
go run server.go
# In the second pane (after splitting)
vim main.go
Now, Alice needs to invite Bob. She uses tmux attach-session with a specific flag to create a "socket" that Bob can connect to:
tmux attach-session -t pair-programming
This command doesn’t create a new session; it attaches the current terminal to the existing pair-programming session. The key for sharing is that tmux creates a socket file (usually in /tmp/tmux-<uid>/ or ~/.tmux/ depending on configuration) that other users can connect to.
Bob, on his machine, simply needs to know Alice’s IP address and the name of the tmux socket. Alice can find her IP address and share it with Bob. Then, Bob runs:
tmux -S /tmp/tmux-alice/pair-programming attach-session -t pair-programming
Here, /tmp/tmux-alice/pair-programming is the path to the socket file that Alice’s tmux server is listening on. Bob’s tmux client connects to this socket, and he’s now inside Alice’s tmux session. He can see her panes, her running processes, and her editor. Bob can then split his own pane and start working on a separate file or running tests:
# Bob splits his pane horizontally
tmux split-window -h
# Bob opens another file in the new pane
vim utils.go
Both Alice and Bob can interact with the same tmux session. If Alice scrolls up in her pane, Bob sees the same scroll. If Bob types in his pane, Alice sees it. They can even send commands to each other’s panes. For instance, Alice can send a command to Bob’s pane:
# Alice runs this in her pane
tmux send-keys -t 1 'echo "Bob, can you check the logs?"' C-m
Here, -t 1 refers to Bob’s pane (assuming it’s the second one, index 1). C-m is the Enter key.
The underlying mechanism is tmux’s server-client architecture. When you start tmux, a server process spins up. This server manages all your sessions, windows, and panes. When you attach-session, your terminal acts as a client connecting to this server. For sharing, the server creates a Unix domain socket. Other tmux clients can connect to this socket, effectively becoming clients of the same tmux server. This means they are all operating within the same shared state managed by that single server process.
The most surprising part about tmux sharing is how it elegantly sidesteps most networking complexities. You don’t need to set up SSH tunneling for every command or worry about complex firewall rules for shared access. As long as Bob can reach Alice’s machine on the network (even if it’s just for the tmux socket connection), and Alice has configured tmux to allow client connections (which is the default), they are in business. The heavy lifting of synchronizing terminal state, input, and output is all handled by the local tmux server.
What most people miss is how to manage multiple people in the same session without stepping on each other’s toes. You can use tmux’s pane naming and window management to delineate responsibilities. For instance, Alice could name her primary coding window "Alice’s Vim" and Bob could name his "Bob’s Tests".
# Alice names her window
tmux rename-window "Alice's Vim"
# Bob names his window
tmux new-window -n "Bob's Tests"
This keeps things organized when you have many panes and windows open.
The next hurdle you’ll likely encounter is managing different shell environments or needing to run commands that require specific sudo privileges, which can get tricky when sharing a single server process.