I spend a lot of my week working alongside an AI coding agent. Not the autocomplete kind that lives in the editor, but the sort you hand a task to and come back to later. It reads the codebase, runs the tests, makes the change, tells you what it found.

The thing nobody warns you about is that these sessions are fragile in a very specific way. All the useful context lives inside the running session. Everything it has learned about the project in the last two hours, the dead ends it already ruled out, the thing you told it at the start that it is still honouring twenty messages later. Close the laptop and that is gone. Start again tomorrow and you are re-explaining yourself.

I wanted the session to be a place I could walk away from and come back to. From a different machine. From my phone, standing in a workshop, without a laptop anywhere near me. Here is how that ended up working, including the part where I got it wrong first.

Step one: put it somewhere that does not sleep

The laptop is the problem. It sleeps, it moves between networks, it gets closed mid-thought. So the session moved to a cloud droplet: a small always-on Linux box, the cheapest tier, doing nothing else.

This is not exotic. It is a machine that stays awake. But it changes the shape of the thing. The agent now lives somewhere with a stable address, its own copy of the repositories it works on, and its own credentials. It is less like a tool I open and more like a colleague who is always at their desk.

Worth being deliberate here, because it is easy to skip past: that box has real access. It can reach production servers, push to git, read databases. Treat it like any other machine with those keys, not like a scratchpad.

Step two: the mistake

My first setup was the obvious one. SSH into the droplet, start the agent, work.

That works fine right up until you close the terminal. When your SSH connection ends, the shell you started ends with it, and everything that shell was running gets a hangup signal. The agent dies. Not gracefully, not with a message, it is simply not there when you come back.

I found this out the way most people do. I had a long session going one evening, closed the laptop, and picked up my phone the next morning to check on it. Nothing. No session, no context, no way to get any of it back from a phone. The entire afternoon's worth of accumulated understanding about the problem I was working on had evaporated because I logged out of a shell.

The obvious lesson is "use nohup" or "run it in the background". Neither is right, because I did not want it running in the background. I wanted to be able to reattach to it. To open my phone, see what it is doing right now, type a follow-up, and leave again.

Step three: tmux, which is the actual answer

tmux is a terminal multiplexer, which is a dry name for something quite simple: it runs a terminal session that is not tied to your connection. You start a session, detach from it, disconnect entirely, come back tomorrow from a different device, and attach to the same session still running exactly where you left it.

That is precisely the property I was missing. The agent runs inside tmux. My SSH connection becomes just a window onto it rather than the thing keeping it alive.

The command I settled on looks like this:

tmux new-session -d -s agent-session -c /path/to/project \
    'claude --continue --remote-control MyProject || claude --remote-control MyProject; exec bash'

A few things in there are doing real work, so it is worth pulling apart.

-d starts it detached, so it does not need a terminal attached to begin with. That matters for the next step.

--continue resumes the most recent conversation rather than starting a fresh one. This is the flag that makes the whole thing worth doing, and it is also where I lost half an hour: it belongs to the main command, not to the remote-control part. Put it in the wrong place and you get a brand new session with none of your history, which looks like it worked until you notice the agent has no idea what you were talking about.

The || is a fallback. If there is no previous conversation to continue, the first command fails and the second one starts a fresh session instead. Without it, a genuinely first run just errors out and you get an empty tmux session and no explanation.

exec bash at the end keeps the session alive if the agent exits. Otherwise the moment the process ends the whole tmux session disappears, taking with it any error message that might have told you why.

Step four: surviving a reboot

tmux survives disconnections. It does not survive the machine restarting. Cloud providers reboot instances for maintenance, kernels get patched, things happen.

So the start command went into a small shell script, and the script goes in cron with a @reboot schedule. Every time the box comes up, the session comes back on its own.

One detail that is easy to leave out and annoying to debug later: the script checks whether the session already exists before starting one.

if tmux has-session -t agent-session 2>/dev/null; then
    exit 0
fi

Without that guard, anything that runs the script a second time stacks another session on top of the first. Now you have two agents in the same working directory, both convinced they are the only one there. That is a genuinely confusing afternoon, and it is four lines to prevent.

What this is actually good for

The obvious win is the phone. I can be away from my desk, open the app, and the session is there, mid-conversation, with all of its context. I can ask what it is doing, read what it found, and point it at the next thing. Then put the phone away.

The less obvious win is continuity, and it turns out to matter more. Because the session persists across days, it accumulates. It knows what we tried on Tuesday and why we abandoned it. When I come back to a problem I have not touched in a week, I do not start by rebuilding context. It is still there.

That changes what you use it for. Short-lived sessions push you towards small, self-contained tasks, because anything longer means re-explaining the project. A session that persists lets you work on something across several sittings, the way you actually work on things.

The honest caveats

This is a long-running process with real credentials sitting on a machine that is always on. That is a reasonable thing to do and also something to be deliberate about. Scope what it can reach. Give it its own user rather than root. Know which production systems those keys open, because a persistent session is a persistent set of permissions.

The other thing: a session that never ends will eventually drift. Context gets long, older details get summarised away, and occasionally the right move is to start fresh rather than continue. Persistence is a default worth having, not a rule worth being religious about.

None of this is complicated. It is one tmux command, a four line guard, and a cron entry. But the difference between an agent I use when I am at my desk and one I can reach from anywhere turned out to be almost entirely those three things.