Keep Claude Code Running After an SSH Disconnect
Your laptop lid closes, or WiFi hiccups for a second, and the SSH session drops. When you reconnect, the Claude Code TUI is gone — not paused, not backgrounded, just gone, task and context with it.
Why the process doesn't just survive on its own
Claude Code's terminal interface needs a real terminal underneath it: it renders a screen, reads keypresses, and streams output to something that behaves like an actual TTY. When the SSH session that carried that connection ends, the process attached to it typically doesn't survive — and this isn't really a "backgrounding" problem, it's a "there's no terminal left for it to talk to" problem. That's also why nohup doesn't save you here: it stops the process from dying when you log out of a shell that keeps running, but it does nothing if the terminal itself disappears out from under a foreground TUI.
Fixes that don't need anything installed beyond a package manager
Run it inside tmux, screen, or zellij
Start claude (or claude remote-control) inside a terminal multiplexer, and the process keeps running on the server after SSH drops — you reconnect and reattach to the same window instead of starting over. Anthropic's own docs recommend exactly this for Remote Control, for the same underlying reason. (Source: official docs)
One practitioner's account of this exact problem is worth reading directly: after an SSH disconnect killed a long-running Claude Code session mid-task, they found that reattaching to a multiplexer was the only thing that actually got them back to where they'd left off, and settled on zellij specifically — their stated reason was that it comes with a full scrollback buffer by default, where they felt tmux/screen needed extra configuration to get comfortable mouse scrolling working. (Reported by a user; not reproduced by us) That's a personal preference, not a universal ranking — tmux and screen do the same core job.
Use mosh instead of plain SSH
Mosh is a different layer: it's designed to survive network changes and brief drops that would otherwise kill a raw SSH connection outright, so you simply hit fewer full disconnects in the first place. It doesn't replace a multiplexer — it complements one, by making the connection itself more resilient.
Where this still leaves a gap
A multiplexer keeps the process alive on the server. It says nothing about what you're carrying with you. You still need a device that can run an SSH client, you need to remember the session name, and you need to manually ssh back in and tmux attach to the right window — none of which is available if the only thing in your pocket is a phone with no terminal app installed. Mosh improves the connection layer, but it doesn't help if what you actually have right now is "just a phone, no laptop, no SSH client."
Where PocketShell fits
The idea is the same one above — protect the session with something like tmux — just with the client swapped out. Instead of "get a laptop, then SSH back into your dev box," the phone itself is the client: it's a self-hosted web app that talks to an agent on your machine directly, so there's no separate SSH app or terminal emulator to install first. The tmux session it manages is the actual source of truth, and output written while you were disconnected gets replayed by sequence number when you reconnect, rather than expecting you to scroll back through history to find where you left off.
It doesn't replace mosh's job either — PocketShell runs over a standard WebSocket plus an application-level replay mechanism, not a transport-layer protocol built to survive dropped packets mid-flight. And it still assumes you have a machine somewhere that stays on to run the agent — the part it removes is needing a decent SSH/tmux client on the phone itself, not needing a server at all.