Five ways a remote coding agent still loses your work
Every thread about running a coding agent overnight ends the same way. Someone describes their agent dying when they closed the lid, and someone else replies: use tmux.
That advice is correct. It is also solving one layer of a five-layer problem, and the other four are the ones that quietly eat a night of work. You can watch this happen in public: Anthropic's own issue tracker has an open cluster of persistence bugs, filed by people who already took the tmux advice.
This is a map of where a remote agent session actually breaks. No product pitch — I run this stack and wanted the layers written down.
Layer 1: the terminal dies
The default failure, and the famous one. Your agent is a child process of your
shell, your shell belongs to a terminal emulator, and the terminal belongs to an
SSH connection. Drop the connection and SIGHUP propagates down. The agent
dies mid-turn.
This is the layer tmux fixes. The tmux server owns the process instead of your SSH session, so the connection can drop without taking the work with it:
ssh me@box
tmux new -As agents
claude
# close the laptop; detach happens for you
Everything below is what remains after you have done this.
Layer 2: the client kills the process anyway
If you use an integrated SSH remote client rather than a raw terminal, the client may own the process lifecycle itself — and tmux never gets a chance to hold it.
This is claude-code#49790, open since April:
When Claude Desktop's SSH remote client disconnects — intentional quit, network drop, laptop lid close — the Claude Code process on the remote server terminates with it. There's no way to reconnect and pick up where you left off.
The issue notes that the workaround "sidesteps the integrated SSH remote feature entirely." That is the important part. The fix for layer 2 is to stop using the nice integrated thing and go back to wrapping the binary by hand. Worth knowing before you rely on the nice integrated thing.
Layer 3: the work happens, and you never see it
This one is genuinely nasty, because nothing crashes.
Your agent keeps running. It completes turns. You reconnect — and the turns that finished while you were away are not in the UI. The work exists on disk and in git; the record of it does not. See claude-code#64393.
The practical consequence: you cannot tell the difference between "the agent did nothing for two hours" and "the agent did four things and the client forgot." Both look identical from the reattached session. If you have ever re-run a task because you could not confirm it ran, this is why.
The mitigation is to stop treating the client as the source of truth. Whatever the agent did should be legible from outside the session — commits, a task tracker, service logs. If the only record of a night's work lives in a TUI scrollback buffer, you have one copy of something you cannot back up.
Layer 4: the process restarts and there is nothing to reattach to
tmux keeps a process alive across your disconnection. It does nothing about the process dying on its own.
Agents OOM. Hosts reboot for kernel updates. A bad tool call takes the runtime with it. When the process comes back, there is no server-side session to reattach to — claude-code#36261 describes this as "a significant limitation for users running Claude Code on always-on servers."
Note the asymmetry the #49790 reporter points out: Codex CLI keeps the session server-side, so reconnecting reattaches, "essentially tmux-style." Different harnesses draw the persistence boundary in different places. If you run more than one, you are running more than one persistence model, and you will eventually reason about the wrong one.
What covers this layer is ordinary service supervision: a restart policy, a
health check, and something that notices when a restart loop starts. systemd
with Restart=always is most of it.
Layer 5: auth expires under you
The least dramatic and most annoying. Long sessions over SSH can hit re-auth prompts — claude-code#57322 reports disconnects requiring re-login roughly every thirty minutes during long conversations.
An interactive re-auth prompt at 3 a.m. is a stopped agent that looks exactly like a working one. Nobody is awake to type anything.
The honest summary
| Layer | What breaks | Does tmux help? |
|---|---|---|
| 1. Terminal death | SIGHUP on disconnect |
Yes |
| 2. Client-owned lifecycle | Client kills the remote process | No — you must bypass the client |
| 3. Reconnect state loss | Completed turns vanish from the UI | No |
| 4. Process/host restart | No server-side session to reattach | No — needs supervision |
| 5. Auth expiry | Silent stop waiting on a prompt | No |
tmux is not the wrong answer. It is a complete answer to layer 1 and no answer at all to layers 2 through 5, and the advice gets repeated as though the whole problem were layer 1.
If you run one agent, on one box, and check on it in the morning, tmux on a €5 VPS is genuinely fine. I am not going to pretend otherwise — a lot of people are correctly served by twenty-five lines of shell and a container. The layers start to matter when you stop watching: when the agent runs unattended, when there is more than one, and when "did it work?" needs an answer that is not a scrollback buffer.
The general shape of the fix is not exotic. Own the process with a supervisor rather than a multiplexer. Put the record of what happened somewhere outside the session. Make sure a stopped agent looks different from a working one, before 3 a.m. and not after.
That is roughly what litwindow does on a dedicated VM, if you would rather not assemble it — but the layers are the same whether you buy them or build them, and they are worth knowing either way.