Letting Claude Test Windows Apps in a VM Instead of on My PC

I recently created Hyper-V Manage, a screen-reader-first tool for managing Hyper-V virtual machines. Part of what drove that was a real problem I run into every day: Claude choosing to run UI tests on my own PC. With Hyper-V Manage in place, I took the next step and had Claude create a way to run that UI testing in a VM instead. Here’s what it does and how you can use it.

The Problem

When Claude tests a Windows desktop app, it runs the app on the same PC you’re using. Windows pop up, focus jumps out from under you, keystrokes meant for the app land wherever you happen to be, and your screen reader starts reading test windows in the middle of what you’re doing. With JAWS or NVDA running, that turns into chaos quickly. I was stopping my own work while Claude tested. That is not a good way to work.

What I Created With Claude

It’s called vmtest, and it lets Claude do all its app testing inside a Hyper-V virtual machine instead of on your PC.

• Nothing opens on your desktop, focus never moves, and no keys reach your apps. Your screen reader stays quiet.
• Claude talks to the VM through a Hyper-V feature called PowerShell Direct, which needs no network and opens no window.
• A small helper inside the VM does the work. It launches the app, reads its accessibility tree, presses buttons, sends keys, types, takes screenshots and runs installers. After every step, it reports back where keyboard focus landed.
• Each piece of work (a repo and branch) gets its own checkpoint, so Claude can stop and come back later with the app still open. When the work is merged, the VM goes back to a clean state.
• Claude reads the app’s accessibility information (control roles, names, states and focus) and reports what it finds.

Everything is in the vmtest folder on GitHub.

Where It Fits

Before building this, I weighed three ways of having Claude test:

• Testing on your own PC, the way Claude does by default. It’s the fastest, and the app runs on your real setup. But it’s exactly the problem: focus jumps, stray keystrokes, and your screen reader talking over you.
• Testing only through GitHub workflows (CI). It never touches your PC. But each check takes minutes, it only runs tests that were written in advance, and Claude can’t explore the app as it goes.
• A test VM on your PC, which is what vmtest is. It never touches your PC either. Results come back in seconds, Claude can explore the app freely, and each task gets a clean, repeatable starting point. The cost is some memory while the VM runs, and keeping the VM’s Windows up to date.

So I use a mix:

• On my PC, as before: builds and tests that never open a window. They don’t get in the way.
• In the VM: anything that opens a window, sends keys, installs or uninstalls, or needs an accessibility check.
• In CI: the full test suite on every pull request, as a safety net.

It’s for Windows desktop apps right now.

A Real Test It Has Already Done

I had another Claude session working on my QuickMail email app. I asked this session to teach that one how to use vmtest, and the two of them sent messages back and forth while I got on with other things.

The QuickMail session installed the app in the VM and checked where focus landed on first run. It then uninstalled the app and confirmed that a new uninstall prompt appeared at the right time, with focus on the safe button. That’s something our automated build checks couldn’t answer. Along the way it reported problems with vmtest itself, and the first session fixed them.

What You Need

• Windows 11 Pro, Enterprise or Education. Home doesn’t have Hyper-V.
• The Hyper-V feature turned on. It’s off by default; step 1 below shows how.
• Enough memory to run a VM next to your own work. The test VM uses about 2 to 8 GB while it runs, and none when it’s saved.
• Claude Code.
• An Arm64 or x64 PC. It works on both; I use a Snapdragon Surface.

Setting It Up

Step 1: Turn On Hyper-V

If Hyper-V isn’t on already, turn it on. It needs a restart afterwards. Either way works.

The old-school way: press Windows+R, type appwiz.cpl and press Enter. Tab to “Turn Windows features on or off” and press Enter. Arrow down to Hyper-V, make sure it’s checked (Space checks it), then choose OK.

Or, from an administrator PowerShell:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Step 2: Join the Hyper-V Administrators Group

Add yourself to the Hyper-V Administrators group, once, from an administrator PowerShell, then sign out and back in. After that, nothing here needs elevation.

Add-LocalGroupMember -Group "Hyper-V Administrators" -Member "$env:USERDOMAIN\$env:USERNAME"

Step 3: Make the Test VM

Make a Windows 11 VM named ClaudeTesting. Hyper-V Manage does this from a Windows ISO with no clicking through Windows setup; it’s in the Hyper-V Manage folder of the same repo. If you’d rather use a script, hyperv-rdp-vm does the same job.

Put the VM on a virtual switch that has internet.

Step 4: Prepare the VM

Run vmtest prepare once. It sets the VM to sign in by itself, installs the helper, and saves the “Clean” checkpoint every test starts from.

Step 5: Teach Claude to Use It

This is the important part. The vmtest folder has a skill file, skill\SKILL.md. Copy it to your own .claude\skills\vmtest folder, and change the path in it to wherever you put vmtest. Claude then reaches for vmtest by itself whenever a task means opening, driving or installing a Windows app.

You can also add one line to your global CLAUDE.md, so it isn’t optional:

Test Windows desktop apps (anything that opens a window, sends keys, or installs) in the test VM with the vmtest skill, never on this PC.

Finally, add a permission rule so vmtest runs without asking you every time. The README shows the exact rule.

A Note on the Password

The test VM’s account uses a throwaway default password. That’s fine for a VM that exists only for testing, but don’t reuse a real password there.

A Reminder

Automated testing only goes so far. vmtest catches a lot before you ever open the app, but actual use still matters: with screen readers, with other assistive technology, and with the different settings and configurations people really use.

If you try this, I’d love to hear how it goes, and what breaks.