15 minutes to an agent that works all night

Answer three questions and I'll give you a checklist built for your setup. Every step tells you why you're doing it, what the command is, how to confirm it worked, and where to look if it didn't. (Is that machine running Windows? Read this first.)

Using Windows?

You picked Windows, so the wizard did not hand you a checklist. Not because one is missing. This path is a different shape from the other three, and half a checklist would do you more harm than none.

It works, but it 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 take the VPS path above. That is usually faster than getting Windows there, and it is not a brush-off — it saves most people an evening.

Why native Windows won't 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 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. Note the order of the argument though: an agent running perfectly on native Windows does not touch the tmux problem. 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

None is a dead end. Knowing them in advance saves you assuming you broke something:

  • Networking. WSL2 runs in a virtual machine with its own IP, behind NAT. The sshd inside it is not reachable from outside that Windows host by default. Two ways around it. Set up netsh interface portproxy on the Windows side to forward the port in — though WSL's IP can change on every restart, so you will be redoing it. Or turn on mirrored networking with networkingMode=mirrored in .wslconfig, which lets WSL share the host's interfaces and drops the port-forwarding step entirely. The second 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. This guide wants a machine that is always on, so WSL has to start at boot and stay up with nobody logged in — usually a scheduled task or a keepalive. On a Mac or a Linux box there is nothing here to think about. This one is WSL's alone.
  • systemd is opt-in. Older WSL has no systemd at all; systemctl does not exist. 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 it is off by default and older installations will not have it.

One more option: keep Windows as 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. The machine you need to set up was never the one in front of you.