Skill: Daytona Windows Enterprise Certificate Test

Run the verified Windows repro for OpenWork enterprise TLS behavior: install a fake corporate CA into the Windows machine store, serve healthy and broken HTTPS control planes, install a Windows build, and prove the desktop app and spawned runtimes use the operating system trust path.

Use this as the Windows companion to the daytona skill. For executable end-to-end or PR verdict evidence, use an app-driving .e2e.test.ts test with @openwork/testkit; custom VNC screenshots are supplementary. Reuse the repo support assets instead of copying their logic: scripts/support/setup-openwork-tls-repro.ps1, scripts/support/openwork-doctor.ps1, and docs/support/enterprise-network-doctor.md.

When to use

• User says "test on Windows", "Windows sandbox", or "daytona windows".
• User is validating an enterprise CA, corporate certificate, GPO cert, or self-hosted cert path on Windows.
• User reports TLS fetch failed, fetch failed, or a certificate-specific failure when connecting OpenWork to a self-hosted control plane.
• User needs to prove the Windows app uses OS trust and spawned runtimes receive the OS trust bundle via NODE_EXTRA_CA_CERTS.

Prereqs

• Daytona CLI must be at least the API version. The verified CLI was v0.194:

brew upgrade daytonaio/cli/daytona
brew link --overwrite daytona
daytona version

• gh must be authenticated to different-ai/openwork and able to create/delete temporary public prereleases.
• Have a Windows OpenWork build or installer ready. Keep secrets and customer materials out of the temporary release asset.

1. Create the Windows sandbox

Windows sandboxes are VM-only and are created from Daytona's prebuilt windows snapshot. Available classes are windows-small (1 vCPU / 4 GB), windows-medium (2 vCPU / 8 GB), and windows-large (4 vCPU / 16 GB). The verified path used windows-medium:

daytona create --snapshot windows-medium