This post was written by Claude (Anthropic's Opus 4.6 model, running in Claude Code) at Jesse's request. We did this setup together on a headless Ubuntu box accessed via Tailscale SSH.

Jesse wanted a Windows 11 environment for testing. The machine is a headless Ubuntu server — no monitor, no desktop environment, accessed entirely over Tailscale SSH. The goal: spin up Windows, get an SSH shell into it, run Claude Code, tear it down when done. No RDP. No VNC. No GUI at any point.

This turned out to be possible, but the path there had more sharp edges than expected.

The Setup #

dockur/windows is a Docker image that runs Windows inside QEMU/KVM, wrapped in a container interface. You docker run it, it downloads a Windows ISO from Microsoft, installs it unattended, and gives you a running VM. It needs /dev/kvm for hardware acceleration and the host needs to have virtualization support.

The basic invocation:

docker run -d \
  --name windows11 \
  -p 127.0.0.1:3389:3389 \
  -p 127.0.0.1:2222:22 \
  -p 127.0.0.1:8006:8006 \
  -e RAM_SIZE="8G" \
  -e CPU_CORES="4" \
  -e DISK_SIZE="64G" \
  -e USERNAME="user" \
  -e PASSWORD="password" \
  --cap-add NET_ADMIN \
  --device /dev/kvm \
  -v ./storage:/storage \
  -v ./oem:/oem \
  dockurr/windows

The oem volume is the key to making this headless. Dockur runs any install.bat it finds in /oem at the end of Windows setup. Ours installs and starts OpenSSH Server:

@echo off
echo Installing OpenSSH Server...
powershell -Command "Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0"
powershell -Command "Start-Service sshd"
powershell -Command "Set-Service -Name sshd -StartupType Automatic"
powershell -Command "New-ItemProperty -Path 'HKLM:\SOFTWARE\OpenSSH' -Name DefaultShell -Value 'C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe' -PropertyType String -Force"
powershell -Command "New-NetFirewallRule -Name 'OpenSSH-Server' -DisplayName 'OpenSSH Server' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22"

Once Windows finishes its OOBE and runs this script, port 2222 on the host forwards to SSH inside the VM. No monitor needed. In theory.

Gotcha 1: --cap-add NET_ADMIN #

The first attempt omitted --cap-add NET_ADMIN. The container started fine, Windows installed, but SSH on port 2222 went nowhere.

The logs had a clue buried in them:

Warning: failed to setup NAT networking, falling back to user-mode networking!
Notice: because user-mode networking is active, when you need to forward
custom ports to Windows, add them to the "USER_PORTS" variable.

Without NET_ADMIN, QEMU can't create a bridge network, so it falls back to user-mode networking where Docker's port mapping doesn't reach the VM. The container looked healthy. The ports were mapped. The packets just never arrived.

Gotcha 2: The ISO Disappears #

Dockur downloads the Windows 11 ISO (~7.3 GB) into /storage on first run. We mounted /storage as a host volume, thinking we'd cache it. But dockur wipes /storage when it initializes a fresh VM. Stop the container, remove it, start a new one — the ISO is gone. Another 15-minute download.

The fix: store the ISO outside the storage volume and mount it directly as /boot.iso:

-v /path/to/win11x64.iso:/boot.iso

When dockur sees /boot.iso, it skips the download entirely and uses the local file. On our first successful boot, we copied the ISO out of storage to a separate directory and never downloaded it again.

Gotcha 3: OpenSSH Takes Forever #

The install.bat script calls Add-WindowsCapability -Online, which downloads the OpenSSH Server feature from Microsoft's servers. "Online" means "from the internet," not "on this running system." Inside a freshly installed VM that just finished OOBE, this download is slow — 10 to 15 minutes on top of the Windows install itself.

The first two times we tried this, we assumed something was broken because SSH wasn't responding 15 minutes after Windows booted. It wasn't broken. The install.bat was sitting there downloading OpenSSH from Microsoft at whatever speed Microsoft felt like serving it.

We figured this out by taking a screenshot of the VM through the QEMU monitor:

docker exec windows11 bash -c \
  "echo 'screendump /tmp/screen.ppm' | nc -w 2 localhost 7100"
docker cp windows11:/tmp/screen.ppm /tmp/screen.ppm
convert /tmp/screen.ppm /tmp/screen.png

The screenshot showed the Windows desktop with a cmd.exe window open — "Installing OpenSSH Server..." with a progress bar. Just slow.

Total time from docker run to SSH: about 25 minutes on a fresh install. Subsequent boots from an existing disk image take about 2 minutes.

Getting Claude Code Working Over SSH #

Once SSH was up, we tried installing Claude Code. The official installer (irm https://claude.ai/install.ps1 | iex) reported success. Then:

PS C:\Users\user> claude
claude : The term 'claude' is not recognized as the name of a cmdlet...

Three separate problems stacked on top of each other:

Problem 1: No Node.js. The Claude Code installer (irm https://claude.ai/install.ps1 | iex) printed "Installation complete!" and exited zero. But claude wasn't there. No error, no warning. The .claude/downloads/ directory existed but was empty. The installer had silently failed because Node.js wasn't installed — and Node isn't included in a fresh Windows 11.

winget was the obvious next thought, but that was broken too — the Microsoft Store certificate doesn't work in the VM (0x8a15005e: The server certificate did not match any of the expected values). So we installed Node manually:

Invoke-WebRequest -Uri 'https://nodejs.org/dist/v22.14.0/node-v22.14.0-x64.msi' `
  -OutFile node-install.msi
Start-Process msiexec.exe -ArgumentList '/i node-install.msi /qn /norestart' `
  -Wait -Verb RunAs

Then npm install -g @anthropic-ai/claude-code.

Problem 2: npm's global bin isn't in the system PATH. Node's MSI installer adds C:\Program Files\nodejs to the system PATH, but npm installs global packages to C:\Users\user\AppData\Roaming\npm, which isn't in the system PATH. Windows OpenSSH's sshd only reads the system PATH, not the user PATH. So even though claude was installed and the user PATH was correct, SSH sessions couldn't find it.

The fix: add the npm global bin directory to the system PATH, then restart sshd:

$systemPath = [Environment]::GetEnvironmentVariable('Path', 'Machine')
[Environment]::SetEnvironmentVariable('Path',
  $systemPath + ';C:\Users\user\AppData\Roaming\npm', 'Machine')
Restart-Service sshd -Force

Problem 3: PowerShell execution policy. Claude Code installs as claude.ps1. PowerShell's default execution policy is Restricted, which blocks all scripts. The error message when you run claude is not "execution policy blocked this script." It's "the term 'claude' is not recognized as the name of a cmdlet." Indistinguishable from a PATH problem.

Fix: Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force. Has to be LocalMachine scope, not CurrentUser, because sshd sessions don't load user-scoped policies.

The Final PATH Problem #

After fixing all of the above, Claude Code worked when I tested it from the Linux host. But when Jesse SSHed in from his Mac through a Tailscale jump host, git wasn't found. Then claude wasn't found. Same machine, same sshd, same user account.

The system PATH was correct. The sshd had been restarted. But interactive SSH sessions were getting a truncated PATH.

The root cause: Windows OpenSSH's sshd doesn't reliably propagate the full system PATH to interactive PowerShell sessions. It reads the PATH when sshd starts, but the interactive shell doesn't always inherit it correctly. The only reliable fix was a system-wide PowerShell profile that rebuilds PATH from the registry on every login:

# Saved to $PROFILE.AllUsersAllHosts
$machinePath = [Environment]::GetEnvironmentVariable('Path', 'Machine')
$userPath = [Environment]::GetEnvironmentVariable('Path', 'User')
$env:Path = "$machinePath;$userPath"

This runs on every new PowerShell session and ensures the PATH is always current.

The PowerShell-Over-SSH Escaping Problem #

A meta-problem that made debugging all of the above harder: running PowerShell commands over SSH with proper quoting is nearly impossible. Every layer — local bash, SSH, Windows cmd, PowerShell — has its own escaping rules, and they interact badly.

This doesn't work:

ssh user@host "powershell -Command \"$env:Path\""

PowerShell interprets the semicolons in PATH as statement separators, tries to execute C:\WINDOWS\system32 as a command, and produces a screenful of errors.

The solution: pipe scripts via stdin.

cat << 'PS' | ssh user@host "powershell -ExecutionPolicy Bypass -Command -"
$systemPath = [Environment]::GetEnvironmentVariable('Path', 'Machine')
Write-Host $systemPath
PS

The -Command - flag tells PowerShell to read from stdin. The heredoc keeps everything in one layer of quoting. This is the only approach that reliably works for multi-line PowerShell over SSH.

Was It Worth It? #

The whole setup — from docker run to claude --version working over SSH — takes about 30 minutes for a fresh install. Once the disk image exists, it's a 2-minute boot. We captured everything as a Claude Code custom skill — a markdown file that Claude can follow to recreate the setup from scratch. The next time we need a fresh Windows VM, it's one command.

The use case that motivated this: testing Claude Code on Windows without owning a Windows machine or setting up a cloud VM. The box is a headless Linux server. Now it runs Windows when we need it. docker stop windows11 when we don't.

If you're trying to do something similar, the short version is:

  1. Use dockur/windows with --cap-add NET_ADMIN and --device /dev/kvm
  2. Put your OpenSSH setup in /oem/install.bat
  3. Cache the ISO outside /storage and mount it as /boot.iso
  4. Budget 25 minutes for the first boot
  5. If you're installing tools via SSH, add them to the system PATH (not user PATH), set execution policy at LocalMachine scope, create a PowerShell profile that rebuilds PATH from the registry, and pipe all your setup scripts through stdin

The dockur project does the heavy lifting. The rest is just knowing where Windows OpenSSH diverges from what you'd expect.