You can run tmux inside a remote tmux session without losing your local state when you disconnect.
Let’s see this in action. Imagine you’re SSH’d into a server, and you’ve started a tmux session there.
# On your local machine:
ssh user@your_server
# On the remote server:
tmux new-session -s work
Now, inside this work tmux session on the server, you want to start another tmux session. This could be for a different project, a sandboxed environment, or just to keep your current work session clean.
# Still inside the remote server's tmux session:
tmux new-session -s nested_project
You’ll notice your prompt changes, indicating you’re now in a new tmux pane within the work session. Your work session is still running in the background, attached to the SSH connection.
(work) 1:bash* 2:bash
(nested_project) 0:bash*
This nested_project session is entirely independent of your local machine’s tmux state. You can detach from nested_project using Ctrl-b d, and you’ll be back in your work session.
(work) 1:bash* 2:bash
(nested_project) detached
You can even detach from the work session by typing exit or pressing Ctrl-d in the work session’s shell. This disconnects your SSH session.
(work) detached
exit
Connection to your_server closed.
When you reconnect and SSH back into the server, you can reattach to your work session:
# On your local machine:
ssh user@your_server
# On the remote server:
tmux attach-session -t work
And inside that work session, you can attach to your nested_project:
# Still inside the remote server's tmux session:
tmux attach-session -t nested_project
This gives you two levels of session management. The outer work session is tied to your primary SSH connection, keeping your main server environment alive. The inner nested_project session provides a dedicated workspace that you can detach from and reattach to, even if you disconnect from the outer session or the SSH connection itself.
The core problem this solves is state persistence across disconnections. Normally, if you’re running a long process or an interactive application directly in an SSH session and your connection drops, that process is gone. tmux on the server solves this by detaching the session from the terminal. Nesting tmux adds another layer of isolation and persistence within that already persistent server session. It’s like having a virtual machine for your terminal applications, but much lighter.
The key is that each tmux server process runs independently. When you start tmux new-session, you’re not just creating a new window; you’re spawning a new server process (or connecting to an existing one) that manages its own set of client connections (your terminal). When you SSH in, your terminal is a client to the outer tmux server. When you tmux new-session inside that, your terminal is acting as a client to the inner tmux server, but the outer tmux server is acting as the terminal for the inner tmux server.
The internal structure is that each tmux instance manages a server process. When you run tmux without arguments, it tries to connect to an existing server. If none exists, it starts one. When you run tmux new-session, it ensures a server is running and then creates a new session managed by that server. The attach-session command connects your current terminal to a specific session managed by a server. By nesting, you’re effectively layering these client-server relationships. Your local terminal connects to the remote tmux server. The remote tmux server’s "window" then displays the output of your local terminal, which is now running as a client to the nested tmux server.
The most surprising part is how seamlessly the input and output streams are piped. When you’re in a nested tmux session, your keystrokes are sent from your local terminal, through the outer tmux session’s connection to the remote tmux server, then down into the shell running inside the nested tmux session. The output from the nested session travels back up the same path. This makes it feel like you’re directly interacting with the nested session, even though there are multiple layers of tmux and SSH involved.
If you encounter issues with keybindings, especially Ctrl-b, ensure you’re aware of which tmux session is currently receiving your input. Pressing Ctrl-b followed by b will send Ctrl-b to the inner tmux session, while pressing Ctrl-b followed by b again will send Ctrl-b to the outer tmux session, effectively passing Ctrl-b through.
The next thing you’ll likely want to explore is how to configure different keybindings for nested sessions to avoid conflicts.