Windows setup
On Windows wraptool up uses the devcontainer runtime, backed by Docker Desktop with WSL2. You can drive it from PowerShell, but running from inside a WSL2 distribution is the smoother path for the container toolchain.
1. Install Docker Desktop with the WSL2 backend
Install Docker Desktop for Windows and enable the WSL2 backend (Settings → General → Use the WSL 2 based engine). Confirm the engine:
docker version2. Install the Dev Containers CLI
wraptool up shells out to the devcontainer command. Install Node (nodejs.org or winget install OpenJS.NodeJS), then:
npm install -g @devcontainers/cli
devcontainer --version3. Install wraptool
Follow the Windows PowerShell install — it verifies the checksum and installs wraptool.exe under %USERPROFILE%\bin. Then:
wraptool version4. Where your config lives on Windows
wraptool follows the XDG base-directory spec, and on Windows the XDG config home defaults to your local app data:
%LOCALAPPDATA%\wraptool\config.yaml
Override per-run with --config or the WRAPTOOL_CONFIG environment variable. On first run wraptool up scaffolds a commented starter there and never clobbers an existing one. Keep keys exactly as scaffolded — the loader silently ignores unknown keys, so a typo like auth_token (the real key is auth_token_file) fails quietly. A minimal config:
mcp:
transport: sse
listen: 127.0.0.1:8717
tools:
git:
binary: 'C:\Program Files\Git\cmd\git.exe'
timeout: 30s
allow:
- subcommand: [push]
flags: ["--set-upstream"]
deny_flags: ["--force", "--force-with-lease"]
deny:
- subcommand: [remote, set-url]binary is single-quoted so the Windows path’s backslashes stay literal. Leave mcp.listen on loopback — for the devcontainer bridge wraptool up rebinds it to 0.0.0.0 and auto-generates the MCP auth token. Validate before launching:
wraptool config validate5. Scaffold the devcontainer and launch
wraptool init devcontainer --harness claude --lang go
wraptool upup starts the shared server, brings up the container via devcontainer up, provisions the harness, wires its MCP config to the host, and drops you into a shell. Host credentials are not mounted; privileged git goes through wraptool’s MCP git tool. Stop with wraptool down (--rm to remove).
The scaffolded harness-pool mount uses ${localEnv:HOME}, which the Dev Containers CLI reads from the host HOME environment variable. Windows shells (PowerShell, cmd) don’t set HOME by default — only USERPROFILE — so if it’s unset the mount source expands to a wrong path and the shared pool won’t attach. Most Windows developers already define HOME (Git and many other tools expect it); if you don’t, set it once to your user profile:
setx HOME %USERPROFILE%Open a new shell afterward so the variable takes effect.
Next steps
- Getting started — the full model and every
updetail. - Dev Containers — every feature option.
- Configuration reference — every config field.