WinQuick GitHub

For Apple Silicon Macs v0.5.1

Instant disposable Windows environments.

Run Windows software from macOS without maintaining a Windows VM.

Use WinQuick for commands, builds, tests, desktop sessions and Windows-only tools. Each run starts clean, returns output and requested artifacts, then discards its writable state.

Install WinQuick View on GitHub
Terminal
$ winquick run -- cmd /c ver
Microsoft Windows [Version 10.0.26100.8972]
macOS Apple Siliconsupported host · ~310 ms warm
Windows & Linuxfuture plan · not supported yet

What you can do

A local Windows target for commands, builds, tests and desktops.

Run Windows software

Run Windows commands, .exe tools, closed-source and vendor utilities, and PowerShell. stdout, stderr and the exit code are returned unchanged.

winquick run -- pwsh -File .\build.ps1

Build and test projects

Copy a workspace into Windows, build or test, and copy back only the artifacts you name. Modern .NET and .NET Framework, including legacy targets, with packages restored offline.

winquick build ./MyApp -c Release

Bring your own tools

Register a Windows toolchain once as a cached volume. Every later run has it on PATH without re-copying it. Verified with Go, Node, Python, Zig and a C compiler.

winquick tool add go --from ./go

Automate desktop applications

Launch a desktop application that runs on Validation OS, capture screenshots, and drive the controls it exposes through Microsoft UI Automation. WPF and WinForms are verified end to end.

winquick ui-test MyApp.csproj --script smoke.uitest

Give agents a Windows runtime

A native MCP server exposes the run, desktop and UI-automation tools over stdio, for Claude, Cursor or any MCP client.

claude mcp add winquick -- winquick mcp

Disposable and offline

Each run discards its writable state; the base image and caches persist. The guest starts with no network device, and only requested artifacts are copied out.

winquick run -w . -a "bin/**" -- dotnet publish -c Release

When to use it

Built for scripted Windows work.

A traditional VM remains the right tool for interactive Windows use. WinQuick is for command-driven workflows: run a task, collect its output, and return to a clean state.

Traditional VM

  • Best for interactive Windows sessions
  • State persists unless you manage snapshots
  • File handoff and cleanup are your responsibility
  • Usually kept running for repeated tasks

WinQuick

  • Command-driven by default
  • Each run starts from a prepared clean state
  • Workspace copied in, requested artifacts copied out
  • Writable run state discarded afterwards
  • Scriptable from a shell, CI and agents

See it work

Common workflows, end to end.

Run a Windows-only tool
$ winquick run -w . -a report.xml -- tools\report.exe --out report.xml
→ report.xml copied to ./winquick-artifacts

Run a Windows executable and copy back the files you name.

Build a legacy .NET Framework project
$ winquick build ./LegacyApp -c Release
→ packages restored offline; built against .NET Framework
→ output copied to ./winquick-artifacts

Build modern .NET or .NET Framework, including legacy targets, with packages restored offline.

Reuse a Windows toolchain
$ winquick tool add go --from ./go-win-arm64
Tool 'go' ready. On PATH in every run.
$ winquick run -w . -a app.exe -- go build -o app.exe .
→ app.exe copied to ./winquick-artifacts

Register a toolchain once; later runs use it from PATH without re-copying it.

Automate a desktop application
$ winquick ui-test MyApp.csproj --script smoke.uitest --out ./shots
→ steps executed against exposed UI Automation controls
→ screenshots written to ./shots

UI Automation drives the controls an application exposes; other apps can still be launched and captured.

Give an agent a Windows runtime
$ claude mcp add winquick -- winquick mcp
→ registered as an MCP server over stdio

The server exposes the run, desktop and UI-automation tools over stdio.

Run a build step in a script
$ winquick run -w . -- cmd /c build.bat
→ exit code returned unchanged

stdout, stderr and the exit code are preserved, so shell and CI logic behave as they would on Windows.

Each run

How a run works.

  1. 1
    Workspace copied inA copy, so changes inside Windows are not copied back.
  2. 2
    Windows runs cleanThe guest starts with no QEMU network device.
  3. 3
    Requested artifacts copied outThe run's writable state is then discarded.

From real runs

Captured from the running product.

A Windows desktop application running in a WinQuick session, over a console showing the Windows build number
A Windows desktop application running in a WinQuick session, over a console showing the real Windows build. Read back from the guest's own framebuffer.
Two winquick run commands reporting the .NET SDK version and installed SDKs from inside Windows
The .NET SDK, running inside the disposable Windows. Output typeset from a real run.
A winquick run command that writes a file inside Windows and copies only the requested artifact back to the host
A workspace goes in; only the file named with -a comes back to the host. Output typeset from a real run.

Performance

Measured warm-run performance.

After setup, WinQuick resumes a prepared Windows state for each run. These figures were measured on Apple Silicon M4 Pro, macOS 26, using a warm prepared guest. The first winquick setup downloads and prepares the runtime once and is not included.

~310 msclean Windows, cmd /c ver
~520 msdotnet --version
~690 msPowerShell 7 start-up
~340 msdesktop session start
~2.9 sgo build to a Windows .exe
~0.7 sprettier formats a JS file

100 runs of cmd /c ver gave p99 319 ms with zero failures. go build and prettier ran offline through tool volumes. Apple Silicon is the supported host; Windows and Linux are a future plan.

macOS, Apple Silicon
StatusSupported
NotesPrepared-state runs, ~310 ms for a trivial command
Windows x86_64
StatusFuture plan
NotesA WHPX code path exists but is not supported; see the repository.
Linux x86_64 / arm64
StatusFuture plan
NotesA KVM code path exists but is not supported; see the repository.
Full host details

Desktop applications

Run and test Windows desktop applications.

The desktop capability starts a headless Windows desktop. Applications that run on Validation OS can be launched and screenshotted; those that expose Microsoft UI Automation can also be inspected and driven by control rather than by pixel. WPF and WinForms are verified end to end — built inside Windows, then driven. An application with no useful automation surface can still be captured, but not driven.

Desktop documentation
A WPF application running inside WinQuick and controlled through Microsoft UI Automation
A desktop session driving an application through Microsoft UI Automation.

Install

Install on macOS.

Supported host

macOS · Apple Silicon

Homebrew is the supported install path. It pulls in QEMU and hivex and is not quarantined by Gatekeeper. A direct archive download is also available, but is unsigned until notarized.

brew install carlbomsdata/tap/winquick
Future plan

Windows & Linux

WinQuick runs on macOS with Apple Silicon today. WHPX and KVM host code paths exist in the repository, but neither is supported or released yet.

Host status
Then install the Windows runtime

Microsoft's Validation OS image is downloaded separately under Microsoft's licence.

winquick setup --accept-microsoft-terms

Scope

Supported scope and boundaries.

  • macOS Apple Silicon — the supported host. Windows and Linux host paths exist in the source but are a future plan.
  • Minimal guest — the guest is Microsoft Validation OS. Tools that require a Windows service it does not include will not run.
  • Desktop automation — controls are driven through UI Automation. Applications without a useful automation surface can be launched and captured, but not driven.
  • Install path — Homebrew is supported today. A direct archive is unsigned until Developer ID notarization is in place.
  • Boundary — WinQuick provides a hardware-VM boundary for your own builds and tools. It is not an audited malware sandbox.
  • Local only — no account, no telemetry, and no background daemon.