# Daytona Windows Cert

Test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed...

- Repository: https://github.com/different-ai/openwork (24362 stars)
- Category: Testing
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: yes, review before use

## Install

Claude Code: `npx skills add different-ai/openwork --skill daytona-windows-cert -g -a claude-code -y`
Codex: `npx skills add different-ai/openwork --skill daytona-windows-cert -g -a codex -y`
Cursor: `npx skills add different-ai/openwork --skill daytona-windows-cert -g -a cursor -y`
Gemini CLI: `npx skills add different-ai/openwork --skill daytona-windows-cert -g -a gemini-cli -y`

## Description

test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating OpenWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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:

```bash
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`:

```bash
daytona create --snapshot windows-medium
```

The rest: https://github.com/different-ai/openwork/blob/HEAD/.opencode/skills/daytona-windows-cert/SKILL.md