Why is Hermes Agent slow in WSL?

Almost always because the files live under /mnt/c instead of the Linux filesystem. Cross-filesystem access in WSL crosses a protocol boundary and is roughly an order of magnitude slower for many-small-file work like skill installs. Keep everything under ~/.hermes.

How do I keep Hermes Agent running in WSL after closing the terminal?

Use tmux to survive closing a shell, or enable systemd in /etc/wsl.conf with [boot] systemd=true and then install the gateway service. Neither survives the Windows machine sleeping — for an agent that must always answer, use a VPS or managed hosting instead.

← All Guides

Guide

Hermes Agent on WSL

Q: Should I install the Hermes gateway service in WSL?

No. Hermes explicitly recommends the foreground command hermes gateway run for WSL, Docker and Termux. WSL distributions do not reliably run a user systemd instance, and the distribution shuts down shortly after the last terminal closes, so the service fails silently.

WSL2 is an officially supported Hermes Agent target, and it is the most comfortable way to run the agent on a Windows machine. But the advice that works on a Linux VPS is actively wrong here — specifically, installing the background service. This guide covers what to do instead.

Short answer: install Ubuntu via wsl --install, run the Hermes install script inside it, and start the gateway with hermes gateway run — the foreground command Hermes explicitly recommends for WSL. Keep all files inside the Linux filesystem, never under /mnt/c.

Why Not the Background Service?

On a normal Linux box you would run hermes gateway install to register a systemd unit. Hermes explicitly recommends the foreground command for WSL, Docker and Termux instead, and the reason is structural: WSL distributions do not reliably run a user systemd instance, and the whole distribution shuts down shortly after you close your last terminal window.

A service you cannot rely on starting is worse than no service, because it fails silently. Use the foreground gateway:

hermes gateway run

Install WSL2

Open PowerShell as Administrator:

wsl --install
# Reboot when prompted, then set a Linux username and password

# Confirm you are on WSL 2, not WSL 1
wsl -l -v

The VERSION column must read 2. WSL 1 lacks the syscall compatibility the agent's tooling expects. Convert if needed:

wsl --set-version Ubuntu 2

Install Hermes Inside WSL

Open the Ubuntu shell (not PowerShell) and run:

sudo apt update && sudo apt install -y curl
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

The installer bundles its own Python 3.11, Node, ripgrep and ffmpeg, so there is nothing to apt-install first. Then verify and configure:

hermes --version
hermes doctor
hermes setup

Everything else in the Ubuntu guide applies inside the WSL distribution, with the service section replaced by what follows.

The Filesystem Trap

This is the mistake that makes people conclude Hermes is slow on Windows. Keep the Hermes home directory on the Linux filesystem:

Path	Verdict
`~/.hermes` (i.e. `/home/you/.hermes`)	Correct — native ext4 speed
`/mnt/c/Users/you/...`	Avoid — every file operation crosses the 9P protocol boundary

Cross-filesystem access in WSL is roughly an order of magnitude slower for the many-small-file work that skill installs and chat history do constantly. If you have already installed under /mnt/c, move it rather than tuning around it.

Keeping the Agent Running

WSL shuts the distribution down shortly after the last shell exits, which takes your agent with it. Three options, in ascending order of reliability:

1. Leave a terminal open with tmux

sudo apt install -y tmux
tmux new -s hermes
hermes gateway run
# Detach with Ctrl-b then d — the session survives inside WSL

Still dies when WSL itself shuts down, but survives closing the shell.

2. Enable systemd in WSL

Modern WSL supports systemd. Add this to /etc/wsl.conf inside the distribution:

[boot]
systemd=true

Then run wsl --shutdown from PowerShell and reopen. With systemd active, hermes gateway install becomes viable — but the distribution still needs to be running for the unit to matter, so this solves supervision, not uptime.

3. Accept that a desktop is not a server

If you need an agent that answers messages while your laptop is closed, WSL is the wrong host. That is not a configuration problem — a Windows desktop sleeps, and a chat agent that sleeps misses messages. Move it to a VPS or a managed instance and use WSL for development.

Reaching the Web UI from Windows

WSL2 forwards localhost, so a gateway bound inside the distribution is reachable from a Windows browser at http://localhost:9119 without extra configuration. If it is not, check that you bound to 127.0.0.1 or 0.0.0.0 rather than a specific interface address.

Common WSL Issues

Agent disappears minutes after closing the terminal

Expected WSL behaviour, not a Hermes bug. See the options above.

Skill installs are extremely slow

Almost always the /mnt/c trap. Confirm with pwd — if it starts with /mnt/, move the install.

Clock skew after the laptop sleeps

WSL clocks can drift across suspend, which breaks TLS handshakes and OAuth token validation with confusing certificate errors. Fix with sudo hwclock -s, or wsl --shutdown and reopen.

Native Windows instead?

Hermes does support native Windows, and its Windows installer bundles a minimal Git Bash. WSL2 remains the smoother path because the agent's shell tooling assumes a POSIX environment.

Run It Somewhere That Stays Awake

OpenClaw Launch runs Hermes Agent on always-on containers, so your agent keeps answering when your laptop is shut. See the best Hermes hosting comparison or system requirements.