Windows Support

[dussab]

Package ToolHive for Windows

[dmjb]

The container images we are using are all Linux containers. It's also not clear to me that any of the MCP servers out there are tested in a native Windows environment. That means that in order to run them under Windows, you need WSL enabled with Docker installed and configured. Assuming a user has such a setup, then they can run ToolHive inside WSL and the deployment/packaging story is the same as for Linux.

In principle, you could have a Windows binary that runs in a Powershell/CMD shell but manages containers running inside Docker/WSL, but it's not clear if this provides enough benefit for end users to justify the extra testing/portability on our side.

[danbarr]

FWIW, Docker Desktop on Windows defaults to the WSL 2 backend (or uses Hyper-V) and has no problem with Linux containers.

But I attempted to build ToolHive on my Windows laptop, but go build .\cmd\thv failed with:

# github.com/StacklokLabs/toolhive/cmd/thv/app
cmd\thv\app\run_common.go:172:3: unknown field Setsid in struct literal of type syscall.SysProcAttr

[dmjb]

@danbarr I assume it will build inside WSL2?

I think it's an open question of whether people want native Windows containers (and not Linux containers running inside WSL2)

[danbarr]

Yes, the CLI does build under WSL2, and it can launch containers into the Docker Desktop instance (it's "shared" - docker commands can be run from both Windows and WSL2 and end up running in the same runtime). And the launched MCPs are accessible from the Windows "side" (I tested with Roo Code running in VS Code for Windows).

But users doing it this way can't benefit from client auto-configuration, I had to add the MCP server manually.

I think the expectation as a Windows user would be that I could run the thv CLI from Windows and have it be able to configure my clients. I wouldn't have any expectation of using Windows containers - nothing does, TBH.