[Feature]: Windows OS for sandbox.

[hnrie]

Preflight

• I searched existing issues and docs before opening this.
• This proposal is grounded in a real Roomote use case, not a broad generated feature list.

Problem

A lot of my projects are for Windows OS only so linux couldnt satisfy them except cross-platform ones.

Current workaround

for c++ windows project i mostly use mingw to build but obviously cannot debug, run, etc

Proposed behavior

Add another full option for a full Windows OS VM

Affected surfaces

Self-hosting or deployment

Self-hosting implications

yes this would require new setups as we are dealing with Windows OS

Alternatives considered

As said in my Current workaround.

Documentation impact

Self hosting docs and general settings docs

[hnrie]

it would be so great if you guys could add Windows OS to sandbox selections!

[roomote-community]

I investigated the current sandbox architecture. Roomote has provider-neutral lifecycle handling, but the worker runtime itself currently assumes Linux (bash, /sandbox, Linux process/network isolation, and a Linux worker image). A full Windows VM would therefore be a new guest-runtime and VM-provider effort rather than another setting on the existing Docker sandbox.

Before maintainers can turn this into a concrete implementation plan, could you clarify the minimum workflow your projects require?

• Could you share one representative project type and its required toolchain, including whether it needs MSVC/Visual Studio Build Tools, a specific Windows SDK, CMake/Ninja, MinGW, or other components?
• Is a command-line environment sufficient for building, running tests, and invoking a debugger, or must Roomote expose an interactive Windows desktop/Visual Studio debugging session?
• Would Windows Server satisfy the project's runtime/API requirements, or do the projects specifically require Windows 10/11?
• What Windows-capable infrastructure do you currently use or expect to self-host on, such as Hyper-V, Azure VMs, AWS EC2, or another hypervisor/provider?
• Could you provide an example of the commands and debugging flow that fail under the current Linux/MinGW workaround, including the debugger involved?

The repository maintainers will separately need to decide the supported VM backend, Windows licensing model, isolation guarantees, and initial capability scope. Those are project decisions rather than requirements you need to design.

Please tag @roomote in your response with the details, and we can use them to produce a repository-grounded implementation plan.