OpenClaw Guide
Running OpenClaw in tmux: Keeping an Agent Alive
tmux is the usual first answer to "my agent stops when I close my laptop", and it is a good one — it is free, already installed on most servers, and solves the problem in one command. It is also worth knowing exactly which part of the uptime problem it solves, because it is a smaller part than most people assume.
What tmux actually does
tmux is a terminal multiplexer. It runs a server process that owns your shell sessions, so those sessions belong to tmux rather than to the terminal window or SSH connection you happen to be using. Disconnect, and the session keeps running; connect again later and you can reattach to exactly where you were.
For an agent, that is the difference between a process that dies the moment your SSH session drops and one that carries on. It also gives you panes and windows, so logs, a shell, and the agent can share one session.
The short version
Start a named session and run the agent inside it:
tmux new -s openclawStart OpenClaw as you normally would inside that session, then detach with Ctrl-b followed by d. The agent keeps running. To come back:
tmux ls # list sessions
tmux attach -t openclaw # reattachYou can close your laptop now and the agent is still running on the server. If OpenClaw is not installed yet, start with the installation guide.
The commands worth memorising
Every tmux command starts with the prefix key, Ctrl-b by default. Press the prefix, release it, then press the second key.
| Action | Keys or command |
|---|---|
| New named session | tmux new -s name |
| Detach from session | Ctrl-b d |
| List sessions | tmux ls |
| Reattach | tmux attach -t name |
| Split horizontally | Ctrl-b " |
| Split vertically | Ctrl-b % |
| Move between panes | Ctrl-b then an arrow key |
| New window | Ctrl-b c |
| Scroll back through output | Ctrl-b [ then arrows, q to exit |
| Kill a session | tmux kill-session -t name |
Copy mode — Ctrl-b [ — is the one people miss most often. Without it you cannot scroll back through an agent's output inside tmux, which makes debugging feel much worse than it needs to.
A layout that works well for agents
One session, split into panes: the agent in one, its logs in another, a free shell in a third. Create the session, then Ctrl-b " and Ctrl-b % to divide the space. Everything about that run stays in one place, and detaching preserves the whole layout.
Where tmux stops helping
This is the part worth being honest about, because tmux is often treated as a complete answer to uptime and it is not one. It solves disconnection. It does not solve any of the following.
It does not restart anything
tmux is not a process supervisor. If the agent throws an unhandled error and exits, the pane keeps the error on screen and nothing else happens. The bot is offline until a human reattaches and notices — which, for a personal agent, often means hours later when someone wonders why it went quiet.
It does not survive a reboot
Sessions live in memory. A kernel update, a host migration, or a power event ends every session on the machine. Unless something starts the agent again at boot, the reboot is a silent outage.
It does not monitor, update, or alert
Nothing tells you the agent stopped answering. Nothing rotates logs, applies updates, reconnects a chat channel that dropped its session, or renews a certificate. Each is a small task; together they are the reason "I will just run it in tmux on a VPS" quietly becomes an ongoing chore.
Rule of thumb: tmux is the right tool while you are working on the agent. Once you are depending on it, you want something that restarts on failure and starts again at boot.
The next step up
If you want to stay self-hosted, move the agent from a tmux session to a supervised service — a systemd unit or a process manager that restarts on failure and starts at boot — or run it under Docker with a restart policy. The VPS guide covers that path.
If the operational side is not what you wanted to spend time on, managed hosting removes it: the instance is supervised, restarts on failure, survives reboots, and is reachable from chat without a terminal anywhere in the loop. Both are legitimate — the mistake is depending on a tmux session as though it were either of them.
OpenClaw and tmux FAQ
Why does my agent stop when I close the terminal?
Closing the terminal or dropping an SSH connection sends a hangup to the processes attached to that session, so the agent dies with the shell that started it. tmux fixes this by owning the process itself — the agent belongs to the tmux server, not to your connection.
How do I detach and reattach a tmux session?
Detach with Ctrl-b d. Reattach with tmux attach -t openclaw, or tmux ls first to see what is running. Ctrl-b is the default prefix — every tmux command starts with it.
Does tmux restart my agent if it crashes?
No, and this is the common misconception. tmux keeps a session alive across disconnects; it does not supervise the process. If the agent exits with an error, the pane just sits there showing the error until you notice. For automatic restarts you need a process manager or a hosted service.
Does tmux survive a server reboot?
No. tmux sessions live in memory and are lost when the machine restarts. Any host that reboots for kernel updates will silently take your agent with it unless something starts it again at boot.