Claude drove a Windows VM so I could use a Windows-only API on a Mac

Some dependencies you refactor around. Some you containerize. And some are the official MetaTrader5 Python package, which talks to a running MT5 terminal through an interface that exists only on Windows. No macOS build, no Linux build, no Docker escape hatch that doesn’t eventually contain Windows anyway.

I was building a trading-analysis platform around MT5 data, and I work on an M2 MacBook. The distance between those two sentences is this post.

The unglamorous answer: a VM

The honest options were: rent a Windows VPS, keep a spare Windows laptop running, or virtualize. I went with Windows 11 in VirtualBox on Apple Silicon — the ARM build of Windows, since an M2 won’t emulate x86 Windows at usable speed, and along the way I got to discover which Windows ISOs are even viable on ARM before settling on Windows 11.

Locally beat the VPS for one reason that matters in trading work: the feedback loop. The MT5 terminal, the Python process, and my editor are all on one machine; there’s no remote desktop between me and a chart.

But here’s the part that made this worth writing up: once the VM existed, I barely touched it. I gave Claude Code the VM’s credentials and let it do the Windows work.

The agent inside the machine

The workflow inverted the usual arrangement. Instead of me clicking through Windows setup dialogs while an assistant watched, the agent ran the setup and I supervised:

• It moved the project files onto the VM’s desktop and laid out the working directory.
• It installed Python and the MetaTrader5 package inside the VM and wired the project to the running terminal.
• It ran the test suite in the VM and iterated on failures — the ordinary code-fix-rerun loop, except the loop was executing inside a virtualized Windows box on a Mac.

There’s something clarifying about watching an agent operate an OS you personally find tedious. Windows administration is almost entirely procedure — sequences of steps that are documented, deterministic, and boring. That is precisely the work agents are good at. My contributions were the ones that actually required me: deciding what the VM was for, providing credentials, and judging the test results.

The debloat script

A fresh Windows install is a crowd. For a VM whose entire purpose is run one trading terminal and one Python process, the crowd is pure overhead — background services, preinstalled apps, telemetry, all of it burning the RAM and CPU I’d carved out of a laptop.

So the agent wrote a debloat script: uninstall everything except the browser and the trading terminal. Watching it generate the removal list was the best kind of comedy — a machine methodically evicting another machine’s bloatware. The result was a Windows install with the personality of an appliance, which is exactly what a purpose-built VM should be. If the VM ever breaks, I don’t repair it; the script means rebuilding is cheap.

The war stories

Virtualizing Windows on Apple Silicon is workable, not smooth. Two incidents worth recording so you don’t repeat them:

The black screen. At some point I enabled 3D acceleration in the VM’s display settings, because more acceleration sounds better. On the next boot: black screen. No error, no safe mode prompt, nothing — the VM was running and displaying nothing. The fix was to flip the setting back from outside the guest with VirtualBox’s CLI, VBoxManage, since the GUI path assumes a working display. Lesson: on this stack, the display settings that sound like upgrades are how you brick the console, and VBoxManage is how you unbrick it.

RAM and core tuning. A VM on a laptop is a negotiation between two operating systems that each believe they own the hardware. Give Windows too little and MT5 crawls; too much and macOS starts swapping and everything crawls. It took a few rounds to find the split where both sides stayed responsive.

Was this all worth it?

For getting unblocked — completely. The platform got built and tested against real MT5 data, from a Mac, without buying hardware or renting a VPS.

For the long term, the story has a second chapter that deserves its own post: for the always-on trading bot work (as opposed to analysis), I eventually pivoted from the Python API to native MQL5, MT5’s own language — which runs in the terminal itself, including the native Mac build, and removes the Windows requirement entirely. The Python codebase didn’t die; it became the frozen reference spec for the MQL5 port. The VM remains the answer for anything that genuinely needs the Python API.

The transferable bits

• A Windows-only dependency is an environment problem, not an architecture problem. Don’t redesign the system; contain the requirement in a VM sized exactly to it.
• Let the agent do the OS work. Environment setup inside a VM is procedural, verifiable, and low-stakes — ideal delegation material. Keep the credentials scoped to a machine you can rebuild.
• Script the rebuild. The debloat/setup scripts are the real asset. A VM you can recreate from scripts is cattle; one you hand-configured is a pet with a Windows license.
• Keep VBoxManage in reach. The GUI stops helping exactly when things get interesting.

The strangest part, in hindsight, is how normal it felt by the end: a Mac, running Windows, being operated by an AI, testing a trading system. The stack is absurd. The unblocked afternoon was real.