test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating iPolloWork Windows enterprise TLS/OS-trust fi
Install
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add Devin-AXIS/iPolloWork --skill daytona-windows-cert -a cursor -y
test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating iPolloWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox.
Questions
How do I install daytona-windows-cert?
Download .opencode/skills/daytona-windows-cert/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does daytona-windows-cert live?
The publisher keeps it at https://github.com/Devin-AXIS/iPolloWork.
Which agents can use daytona-windows-cert?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating iPolloWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox.
name: daytona-windows-cert
description: "test on Windows, enterprise CA, corporate certificate, GPO cert, TLS fetch failed, Windows sandbox, daytona windows, self-hosted cert. Use when validating iPolloWork Windows enterprise TLS/OS-trust fixes in a Daytona Windows sandbox."
Skill: Daytona Windows Enterprise Certificate Test
Run the verified Windows repro for iPolloWork 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 daytona-electron-test. Use fraimz when
the result needs frame-by-frame proof, screenshots, or PR evidence. Reuse the
repo support assets instead of copying their logic: scripts/support/setup-ipollowork-tls-repro.ps1,
scripts/support/ipollowork-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 iPolloWork 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 Devin-AXIS/iPolloWork and able to create/delete
temporary public prereleases.
Have a Windows iPolloWork 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
The command prints a sandbox ID and a web terminal URL. Save the ID once:
SANDBOX_ID="<SANDBOX_ID>"
Windows sandboxes may auto-stop. Restart the sandbox before continuing:
daytona sandbox start <ID>
Use the saved shell variable for later commands:
daytona sandbox start "$SANDBOX_ID"
2. exec vs VNC (the session-0 trap)
Important:daytona ssh <ID> is interactive-only and fails from scripts on
the host-key prompt. Use this shape for setup commands instead:
daytona exec <ID> -- <cmd>
For example:
daytona exec "$SANDBOX_ID" -- whoami
daytona exec runs as nt authority\system in Windows session 0. That is useful
for admin setup, but it cannot see the interactive VNC user's app UI, and
$env:APPDATA resolves to the SYSTEM profile, not C:\Users\Administrator.
Do not inspect app UI state, userData, or installed app settings through SYSTEM
profile paths.
Human GUI access is: Daytona Dashboard -> sandbox -> ⋮ menu -> VNC ->
Connect. Use exec for setup and logs; use VNC to drive the installed iPolloWork
app and observe the user-visible result.
3. Get the app build in
For large Windows builds, zip the build, attach it to a temporary public
prerelease, and download it inside the VM with the Windows-bundled curl.exe
and tar. The curl.exe 8.x and tar binaries ship in the Windows image.
From the repo root on the host, stage a zip that expands under C:\ow. Include
the app build plus the support scripts from this repo so the VM reuses the
checked-in harness:
TAG="ipollowork-win-cert-repro-$(date +%Y%m%d%H%M%S)"
ZIP="/tmp/${TAG}.zip"
# Put your Windows app build under /tmp/ipollowork-win-cert-upload/ipollowork/app
# and include scripts/support/setup-ipollowork-tls-repro.ps1 plus
# scripts/support/ipollowork-doctor.ps1 under ipollowork/scripts/support/.
# Include .opencode/skills/daytona-windows-cert/scripts/ca-probe.js as
# ipollowork/ca-probe.js.
ditto -c -k --keepParent /tmp/ipollowork-win-cert-upload/ipollowork "$ZIP"
gh release create "$TAG" "$ZIP" --repo Devin-AXIS/iPolloWork --prerelease
The release command shape from the verified session was:
scripts/support/setup-ipollowork-tls-repro.ps1 creates a fake corporate root and
intermediate, trusts the root in Cert:\LocalMachine\Root, maps
poc.ipollowork.test to localhost, and serves:
https://poc.ipollowork.test:8443 — healthy chain.
https://poc.ipollowork.test:9443 — broken chain with the intermediate removed.
Do not run the listeners only inside a one-off daytona exec; the PowerShell
listeners die when that exec session closes. Persist them with a scheduled task
that runs as SYSTEM and keeps the session alive:
This is the crucial #2562 verification for the GPO/enterprise-CA case: the
Windows system store (LocalMachine\Root) contains the repro corporate CA, while
the bundled Mozilla roots do not.
Verify the installed app via VNC
Drive the installed iPolloWork Windows app through VNC, not daytona exec.
Open Daytona Dashboard -> sandbox -> ⋮ menu -> VNC -> Connect.
Launch or install iPolloWork as the interactive user.
Point the self-hosted/control-plane URL at https://poc.ipollowork.test:8443.
The request should succeed.
Repeat against https://poc.ipollowork.test:9443. The request should fail with
a named certificate/chain error, not a vague fetch failed banner.
Use daytona-electron-test for normal Electron driving patterns and fraimz for
captured proof if this is PR evidence.
Known gotcha: system-ca-bundle.pem is written once at first launch and then
memoized. If a CA is added after first launch, restart the app before
expecting it to appear. On real fleets the GPO CA is present at boot, so this
usually does not bite customers.
Shell/quoting gotchas
zsh strips backslashes in unquoted Windows paths. Quote the whole cmd /c
payload:
Pipes and | inside daytona exec ... -- powershell -Command '...' can be
eaten by the intermediate cmd layer. Use powershell -EncodedCommand with a
base64 UTF-16LE payload for anything with pipes or nested quotes:
Stop the scheduled repro, remove the certificates/hosts/bindings through the
checked-in setup script, delete the sandbox, and delete the temporary prerelease:
Download .opencode/skills/daytona-windows-cert/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does daytona-windows-cert live?
The publisher keeps it at https://github.com/Devin-AXIS/iPolloWork.
Which agents can use daytona-windows-cert?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.