[Feature] Native Windows support — working setup & guide (no Docker/WSL2)

[markwang2658]

What I got working

Hermes WebUI running natively on Windows 10/11 — no Docker, no WSL2, no VM overhead.

Guide: https://github.com/markwang2658/hermes-windows-native-guide

Setup: https://github.com/markwang2658/hermes-windows-native

How I bypassed the "Windows not supported" bootstrap

Your README says Native Windows is not supported for this bootstrap yet. I worked around it with:

1. Manual env vars — set HERMES_WEBUI_AGENT_DIR, HERMES_WEBUI_STATE_DIR, HERMES_WEBUI_HOST, HERMES_WEBUI_PORT in PowerShell before launching
2. Direct server.py invocation — skipped ctl.sh start / bootstrap.py entirely, called python hermes-webui/server.py directly
3. Isolated state dir — used ~/.hermes/webui-win to avoid conflicts with any WSL installations

WebUI-specific notes on Windows

• ✅ Chat, workspace browser, session management all work
• ✅ 7 themes render correctly
• ✅ Settings panel saves config properly
• ⚠️ File paths in workspace browser show POSIX-style / sometimes (minor)
• ⚠️ Some shell commands from agent tools assume bash (expected)

Memory comparison

Setup	RAM usage
WSL2 + Docker	~1080 MB
WSL2 only	~800 MB
Native Windows (mine)	~330 MB

What could be upstreamed

A start.ps1 equivalent of ctl.sh start would let Windows users skip the bootstrap entirely. Happy to contribute scripts or test PRs.

[nesquena-hermes]

Thanks @markwang2658 — useful field report and a meaningful memory delta vs. WSL2/Docker (~330 MB vs ~1080 MB).

Two things worth separating here:

1. Your guide as-is — already valuable to the next Windows user who lands on the README's "Native Windows is not supported for this bootstrap yet" line. I'll link your repo from the README's Windows section as a community-maintained native setup pointer (PR-able by anyone — happy to take a small docs-only PR if you'd like).

2. Upstreaming a start.ps1 / native bootstrap — this is the bigger ask, and it's where the trade-off lives. The current bootstrap (bootstrap.py + ctl.sh) handles three things you sidestep manually: dependency resolution into the agent venv, state_dir/agent_dir discovery, and a stable PID/log layout for restarts. A native Windows path would need to either (a) reproduce that machinery in PowerShell, or (b) make bootstrap.py itself Windows-aware (more code in one place but fewer divergent code paths). Option (b) is the better long-term shape but it's a real chunk of work, and the maintenance cost is non-trivial (Windows CI runner, path-separator audit across the file tree, line-ending tests).

Marking this as hold + Product Review for now — it's not a blocker for the next sprint, but it's a real feature request and worth a deliberate scoping decision rather than landing piecemeal. If you want to drive option (a) as a starter PR (start.ps1 + a "Native Windows" README section that links your guide), that's a clean, contained, low-risk PR I'd merge.

[nesquena-hermes]

Both halves resolved in v0.51.121:

• start.ps1 native Windows launcher landed via feat: native Windows community-guide link + start.ps1 launcher (#1952) #2783 by @Koraji95-coder
• README community-Windows-guide link landed in the same PR pointing at @markwang2658's hermes-windows-native-guide and hermes-windows-native repos
• Thanks to both contributors for closing this out together.