15 minutes to an agent that works all night

Setting up an agent that works all night takes about fifteen minutes: SSH into a machine you own, tmux so a dropped phone connection detaches instead of stopping the agent, and Tailscale so no port faces the public internet. Answer three questions about your machine, your agent, and where you connect from, and the wizard builds the checklist.

Every step says why you're doing it, what to run, how to check that it worked, and where to look if it didn't. (Is that machine running Windows? Read this first.)

Native Windows has no tmux, so use WSL2

You picked Windows, so the wizard did not hand you a checklist. That path works differently from the other three, and half a checklist would do you more harm than none.

Windows can work, but the route goes through WSL2 and takes a few more steps than a Mac or a Linux box. If all you want is an agent working through the night, rent the cheapest cloud VPS you can find and follow the VPS path above. That is usually faster than getting Windows there, and it saves most people an evening.

Why won't native Windows do?

This guide rests on three pieces: the CLI, tmux, SSH. SSH is fine. Windows 10 and 11 both ship an OpenSSH Server you can switch on, and you will get a PowerShell prompt.

tmux is the problem. There is no native Windows build, and tmux is the load-bearing piece of this whole guide. Without it your phone connection drops, the agent gets SIGHUP, and it dies (the mechanism). "Put your phone away and it keeps running" stops being true. You would have a Windows machine you can SSH into, which is not what this guide is offering.

Whether the agents themselves run on Windows varies by tool and changes quickly, so there is deliberately no list here; check the documentation for the one you plan to use. Mind the order of the argument: an agent that runs perfectly on native Windows still has no tmux. Running and surviving a disconnect are separate questions.

The recommended route: WSL2

Inside WSL2 you have a complete Linux: tmux, sshd, and the agents behave the way they do on real Linux. Install a distribution and every step of the "Linux box" path applies. Go back up and answer the first question that way.

Three snags that don't exist on Mac or Linux

Knowing them in advance keeps you from assuming you broke something:

  • Networking. WSL2 runs in a virtual machine with its own IP, behind NAT, so by default nothing outside that Windows host can reach the sshd inside it. There are two ways around it. Forward the port on the Windows side with netsh interface portproxy, and expect to redo it, because WSL's IP can change on every restart. Or turn on mirrored networking, networkingMode=mirrored in .wslconfig, so WSL shares the host's interfaces and the port-forwarding step goes away. Mirrored networking is much cleaner and needs a reasonably recent Windows 11.
  • WSL doesn't stay running on its own. When the last process exits, the distribution shuts down within seconds and takes the virtual machine with it. You want the machine to stay always on, so WSL has to start at boot and keep running with nobody logged in, usually through a scheduled task or a keepalive. There is nothing to do about that on a Mac or a Linux box.
  • systemd is opt-in. Older WSL has no systemd at all, so systemctl does not exist, and the systemd commands in the wizard's "enable the SSH service on the Linux box" step fail outright. Newer versions turn it on with systemd=true in /etc/wsl.conf, but the default is off.

What if your Windows PC is the client?

The Windows discussed here is always the machine you connect to. If your Windows PC is the computer you work at, and the agent runs somewhere else (a Mac mini at home, a Linux box at the office, a VPS), none of the above applies. The guide works for you as written, and the machine to set up is not the one in front of you.