How to run an always-on agent on Windows with Task Scheduler and WSL

Two routes, and the folklore is out of date

The advice I kept reading in 2026 guides was that Windows means WSL2, full stop, because the open-source agents do not run natively. That was true for a while and the documentation now says otherwise for both projects I checked.

• OpenClaw documents a native Windows install through its PowerShell installer (install.ps1), checked with openclaw doctor and openclaw gateway status. For unattended startup on native Windows it uses a Windows scheduled task, which the docs say can run before login without storing a password, as long as the task is registered from an elevated terminal as the intended user. The same docs say WSL2 remains the most Linux-compatible Gateway runtime on Windows.
• Hermes Agent's README lists Linux, macOS, WSL2 and native Windows, with a PowerShell one-liner for the native install and the words fully supported. The Windows section says the installer delegates Python, Node.js, ripgrep and FFmpeg to a package manager.

So the choice is real. If you want the simplest path and the vendor supports native Windows, take it. If you want the eleven Linux guides in this series to apply to your machine word for word, including the systemd units, the dedicated user and the timers, take WSL2. I would take WSL2, because every other machine I run an agent on is a Unix, and I want one mental model.

What the WSL documentation says about systemd

Microsoft's page on systemd in WSL says the current Ubuntu installed with wsl --install uses systemd by default. For any other distribution, or an older install, you enable it by hand: check that WSL is version 0.67.6 or newer with wsl --version, add two lines to /etc/wsl.conf inside the distro, shut WSL down from PowerShell, and start it again.

/etc/wsl.conf, inside the distro[boot]
systemd=true

PowerShellwsl --version
wsl --shutdown
# then open the distro again and, inside it:
# systemctl status
# systemctl list-unit-files --type=service

The same page adds that on Debian or Ubuntu you should have both the systemd and systemd-sysv packages installed. And it carries a sentence I would underline in red, because it is the difference between a WSL agent that works and one that quietly stops: systemd services will NOT keep your WSL instance alive. WSL shuts an idle instance down. The configuration page lists the defaults: vmIdleTimeout of 60,000 milliseconds for the virtual machine, and under [general] an instanceIdleTimeout of 15,000 milliseconds for a distribution, which it says can be set to -1 to disable the automatic shutdown. If it were my machine, this is the first thing I would check: start the agent, close every terminal, wait a minute, and see whether it is still there.

Keeping it alive after you log out

This is where the WSL route gets specific, and I am quoting OpenClaw's Windows page because it is the clearest statement of the pattern I found. For a headless machine that should start the Gateway before anyone logs into Windows, it gives three steps: enable lingering, install the gateway as a user service inside WSL, and create a Windows scheduled task that starts the distro. It also says the task should run as your own account, not SYSTEM, because per-user WSL distros are not visible to the SYSTEM account. Verification is a plain systemctl --user status of the gateway unit.

Lingering is a systemd concept, not a WSL one: by default, a user's services stop when the user's last session ends, and loginctl enable-linger tells systemd to keep that user's manager running with no session at all. On a bare-metal Linux box I set it for the agent user every time; inside WSL the documentation suggests the same.

Inside the distrologinctl enable-linger $USER
loginctl show-user $USER | grep Linger

The scheduled task is the Windows half. Task Scheduler can run a program at startup or at logon, as a named user, with the option Run whether user is logged on or not. The program is wsl.exe with your distribution name, which is enough to start the instance and, with systemd enabled and lingering on, your user services with it. I would create it in the Task Scheduler window rather than from the command line the first time, so the account and the logged-on-or-not option are visible, and I would reboot to test it, not just run it.

PowerShell, one way to register the task (adjust the distro name)schtasks /Create /TN "WSL agent host" /SC ONSTART /RU "$env:USERNAME" /RL HIGHEST ^
  /TR "wsl.exe -d Ubuntu --exec sleep infinity"
# the /RU user is you, not SYSTEM: per-user distros are invisible to SYSTEM

Memory, disk and where the files live

Two settings from Microsoft's configuration page that I would set before installing anything. %UserProfile%\.wslconfig controls the virtual machine for all WSL2 distributions, and by default it may use 50 percent of the machine's memory and all logical processors. For a box that also has to be a desktop, cap it. Changes take effect after wsl --shutdown; the page also notes an eight-second rule, meaning the subsystem keeps running briefly after the last window closes, so a quick relaunch can miss your change.

%UserProfile%\.wslconfig[wsl2]
memory=4GB
processors=2
swap=2GB

[general]
# keep an idle distribution alive instead of shutting it down after 15 seconds
instanceIdleTimeout=-1

On disk, keep the agent, its virtual environment and its memory database on the Linux side, under the distro's own filesystem, not under /mnt/c. Microsoft's performance guidance for WSL has said for years that cross-filesystem access is slow, and an agent writes small files constantly. Back the Linux files up from inside the distro, with the same tools the Linux guides use.

Step by step, as I would do it

Written as a checklist I would follow at someone else's desk, with the verification after each step, because that is the only way I know to run a platform I cannot test.

1. Install WSL and a current Ubuntu. wsl --install from an elevated PowerShell. Reboot. Check wsl --version is 0.67.6 or newer and wsl --list --verbose shows version 2.
2. Confirm systemd is the init. Inside the distro, systemctl status should show a running system. If it does not, add the two lines to /etc/wsl.conf, run wsl --shutdown, and try again.
3. Cap the machine with .wslconfig, then disable the idle shutdown. Memory and processors to a share you can live with on a desktop; instanceIdleTimeout to -1 so the distribution is not stopped for being quiet. Shut down and relaunch.
4. Create the agent user and follow the Linux core guide. A dedicated user, a virtual environment, a systemd user service with a restart policy, secrets in a root-owned file, a timer for scheduled work. The series page lists the Linux guides as they go live; the Ubuntu one is the closest match to a WSL distro.
5. Install the agent on the Linux side. OpenClaw's Linux installer or Hermes Agent's curl-and-bash line, run inside the distro, with the files under the distro's home directory, never under /mnt/c.
6. Enable lingering for the agent user. loginctl enable-linger agent, so the user's services keep running after every terminal is closed.
7. Add the Windows scheduled task that starts the distro. At startup, as your own account, run whether logged on or not, program wsl.exe with the distro name. Reboot, do not log in, and check from your phone that the agent answers.
8. Or, take the native route instead. Run the vendor's PowerShell installer, let it register its own scheduled task from an elevated terminal, and verify with the vendor's status command. Simpler, and the Linux guides no longer apply.

What I would check first, in order

If I sat down at the machine tomorrow, these are the four things I would test before trusting it with anything, each of them a place where the documentation told me to expect trouble.

1. Does the distro survive a closed terminal? Start the agent, close every window, wait two minutes, open PowerShell and run wsl --list --running. If it is gone, the idle timeout is still on.
2. Does it survive logout? Log out of Windows, log back in, check systemctl --user status for the agent. If not, lingering is off or the service is a system unit running as the wrong user.
3. Does it survive a reboot with nobody logging in? Reboot, wait at the login screen, message the agent from a phone. This is the scheduled task's job, and the one most guides never actually test.
4. Does the network come up before the agent does? The same lesson as on my Mac: a job that starts before DNS resolves fails on its first call. Build the wait into the agent's start script regardless of platform.

That is the whole guide, and its limits. The identity rule from the rest of this series applies unchanged: the agent runs as its own user with its own API key or service account, never as you, and the permissions post says why. If a reader runs this on real hardware and finds a step that does not match, I will correct the page and say so at the top. The series is on one page, and the agent I run for social video, which needs no Windows machine at all, is here.

Sources

1. Microsoft Learn, Use systemd to manage Linux services with WSL (accessed October 20, 2026)
2. Microsoft Learn, Advanced settings configuration in WSL (wsl.conf and .wslconfig) (accessed October 20, 2026)
3. OpenClaw documentation, Windows (accessed October 20, 2026)
4. Nous Research, Hermes Agent README (accessed October 20, 2026)

Written by Lera Leonteva. Nothing on this page was run by me. It is the documentation, read carefully, with the checks I would do first.