本文へ移動
cccskills
無料GitHub で公開

daytona-windows-cert

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.

インストール方法を見る

含まれるファイル(2)

  • SKILL.md12.6 KB
  • scripts/ca-probe.js916 B

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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

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 OpenWork 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="openwork-win-cert-repro-$(date +%Y%m%d%H%M%S)"
ZIP="/tmp/${TAG}.zip"
# Put your Windows app build under /tmp/openwork-win-cert-upload/openwork/app
# and include scripts/support/setup-openwork-tls-repro.ps1 plus
# scripts/support/openwork-doctor.ps1 under openwork/scripts/support/.
# Include .opencode/skills/daytona-windows-cert/scripts/ca-probe.js as
# openwork/ca-probe.js.
ditto -c -k --keepParent /tmp/openwork-win-cert-upload/openwork "$ZIP"
gh release create "$TAG" "$ZIP" --repo different-ai/openwork --prerelease

The release command shape from the verified session was:

gh release create <tag> <zip> --repo different-ai/openwork --prerelease

Download and extract inside Windows:

DOWNLOAD_URL="https://github.com/different-ai/openwork/releases/download/${TAG}/$(basename "$ZIP")"
daytona exec "$SANDBOX_ID" -- cmd /c 'mkdir C:\ow 2>NUL'
daytona exec "$SANDBOX_ID" -- cmd /c "curl.exe -L -o C:\ow\app.zip $DOWNLOAD_URL"
daytona exec "$SANDBOX_ID" -- cmd /c 'tar -xf C:\ow\app.zip -C C:\ow'

The Windows download/extract shape from the verified session was:

daytona exec "$SANDBOX_ID" -- cmd /c 'curl.exe -L -o C:\ow\app.zip <release-download-url>'
daytona exec "$SANDBOX_ID" -- cmd /c 'tar -xf C:\ow\app.zip -C C:\ow'

If the zip only contains the app, fetch the support scripts from the same branch instead of rewriting them:

daytona exec "$SANDBOX_ID" -- cmd /c 'mkdir C:\ow\openwork\scripts\support 2>NUL'
daytona exec "$SANDBOX_ID" -- cmd /c 'curl.exe -L -o C:\ow\openwork\scripts\support\setup-openwork-tls-repro.ps1 https://raw.githubusercontent.com/different-ai/openwork/dev/scripts/support/setup-openwork-tls-repro.ps1'
daytona exec "$SANDBOX_ID" -- cmd /c 'curl.exe -L -o C:\ow\openwork\scripts\support\openwork-doctor.ps1 https://raw.githubusercontent.com/different-ai/openwork/dev/scripts/support/openwork-doctor.ps1'

4. Stand up the enterprise-TLS repro

scripts/support/setup-openwork-tls-repro.ps1 creates a fake corporate root and intermediate, trusts the root in Cert:\LocalMachine\Root, maps poc.openwork.test to localhost, and serves:

  • https://poc.openwork.test:8443 — healthy chain.
  • https://poc.openwork.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:

ENCODED=$(python3 - <<'PY'
import base64
script = r'''
$ErrorActionPreference = "Stop"
$repo = "C:\ow\openwork"
$cmdPath = "C:\ow\start-openwork-tls-repro.cmd"
$cmd = @"
@echo off
cd /d "$repo"
powershell -NoProfile -ExecutionPolicy Bypass -File scripts\support\setup-openwork-tls-repro.ps1
powershell -NoProfile -ExecutionPolicy Bypass -Command "while (`$true) { Start-Sleep -Seconds 3600 }"
"@
Set-Content -LiteralPath $cmdPath -Value $cmd -Encoding ASCII
schtasks /create /f /sc onstart /ru SYSTEM /tn OpenWorkTlsRepro /tr $cmdPath
schtasks /run /tn OpenWorkTlsRepro
'''
print(base64.b64encode(script.encode("utf-16le")).decode())
PY
)
daytona exec "$SANDBOX_ID" -- powershell -NoProfile -ExecutionPolicy Bypass -EncodedCommand "$ENCODED"

Verify the healthy listener is up:

daytona exec "$SANDBOX_ID" -- cmd /c 'netstat -ano | findstr :8443'

Optional diagnostic output from the checked-in doctor script:

daytona exec "$SANDBOX_ID" -- powershell -NoProfile -ExecutionPolicy Bypass -File 'C:\ow\openwork\scripts\support\openwork-doctor.ps1' -WebUrl https://poc.openwork.test:8443 -ApiUrl https://poc.openwork.test:9443 -ExpectedIssuerMatch "OpenWork TLS Repro"

5. Verify the fix

Probe Electron's view of the Windows machine store

Copy .opencode/skills/daytona-windows-cert/scripts/ca-probe.js into the VM as C:\ow\ca-probe.js. Its contents are intentionally small and reusable:

daytona exec "$SANDBOX_ID" -- cmd /c 'copy C:\ow\openwork\ca-probe.js C:\ow\ca-probe.js'
const { X509Certificate } = require("node:crypto");
const tls = require("node:tls");

const needle = (process.env.OPENWORK_TLS_REPRO_CA_MATCH || "OpenWork TLS Repro").toLowerCase();

function countMatchingSubjects(certificates) {
  let count = 0;
  for (const pem of certificates) {
    try {
      const certificate = new X509Certificate(pem);
      if (certificate.subject.toLowerCase().includes(needle)) count += 1;
    } catch {
      // Ignore entries that are not parseable X.509 certificates.
    }
  }
  return count;
}

const system = tls.getCACertificates("system");
const bundled = tls.getCACertificates("default");

const result = {
  systemCount: system.length,
  reproInSystem: countMatchingSubjects(system),
  defaultCount: bundled.length,
  reproInDefault: countMatchingSubjects(bundled),
};

console.log(JSON.stringify(result, null, 2));

if (result.reproInSystem === 0) {
  process.exitCode = 1;
}

Run Electron in node mode. Adjust the executable path for your unpacked build or installed app:

daytona exec "$SANDBOX_ID" -- cmd /c 'set ELECTRON_RUN_AS_NODE=1 && "C:\ow\openwork\app\OpenWork.exe" C:\ow\ca-probe.js'

The verified result was:

{"systemCount":42,"reproInSystem":6,"defaultCount":150,"reproInDefault":0}

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 OpenWork Windows app through VNC, not daytona exec.

  1. Open Daytona Dashboard -> sandbox -> ⋮ menu -> VNC -> Connect.
  2. Launch or install OpenWork as the interactive user.
  3. Point the self-hosted/control-plane URL at https://poc.openwork.test:8443. The request should succeed.
  4. Repeat against https://poc.openwork.test:9443. The request should fail with a named certificate/chain error, not a vague fetch failed banner.

Use the daytona skill for normal Electron driving patterns. If this is PR evidence, translate the user-visible path and TLS assertions into an evals/specs/<slug>.e2e.test.ts test via write-a-spec, run it with run-tests, and use its ambient test evidence for the verdict. The VNC checklist and captures above remain supplementary setup and debugging evidence.

Verify the app's generated CA bundle path

The real Windows userData folder is:

C:\Users\<User>\AppData\Roaming\com.differentai.openwork

It is not C:\Users\<User>\AppData\Roaming\OpenWork. Because exec runs as SYSTEM, inspect the interactive user path explicitly:

daytona exec "$SANDBOX_ID" -- cmd /c 'dir "C:\Users\Administrator\AppData\Roaming\com.differentai.openwork\system-ca-bundle.pem"'
daytona exec "$SANDBOX_ID" -- cmd /c 'findstr /c:"OpenWork TLS Repro" "C:\Users\Administrator\AppData\Roaming\com.differentai.openwork\system-ca-bundle.pem"'

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:
daytona exec "$SANDBOX_ID" -- cmd /c 'dir "C:\Users\Administrator\AppData\Roaming\com.differentai.openwork"'
  • 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:
ENCODED=$(python3 - <<'PY'
import base64
command = r'Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like "*OpenWork TLS Repro*"'
print(base64.b64encode(command.encode("utf-16le")).decode())
PY
)
daytona exec "$SANDBOX_ID" -- powershell -NoProfile -ExecutionPolicy Bypass -EncodedCommand "$ENCODED"
  • %ERRORLEVEL% expands at parse time in cmd one-liners. Prefer PowerShell and $LASTEXITCODE when you need to propagate exit codes:
daytona exec "$SANDBOX_ID" -- powershell -NoProfile -ExecutionPolicy Bypass -Command 'curl.exe --version; exit $LASTEXITCODE'
  • cmd /c plus timeout fails with "input redirection is not supported" under daytona exec. Use ping -n for sleeps:
daytona exec "$SANDBOX_ID" -- cmd /c 'ping -n 6 127.0.0.1 >NUL'

Cleanup

Stop the scheduled repro, remove the certificates/hosts/bindings through the checked-in setup script, delete the sandbox, and delete the temporary prerelease:

daytona exec "$SANDBOX_ID" -- cmd /c 'schtasks /end /tn OpenWorkTlsRepro'
# Core repro cleanup shape: setup-openwork-tls-repro.ps1 -Cleanup
daytona exec "$SANDBOX_ID" -- powershell -NoProfile -ExecutionPolicy Bypass -File 'C:\ow\openwork\scripts\support\setup-openwork-tls-repro.ps1' -Cleanup
daytona sandbox delete <ID>
gh release delete <tag> --yes

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Add a new feature, put work behind a feature flag, roll something out (per organization, for everyone, cloud or self-hosted), revert or kill a feature, or make a big change to existing behavior such as a new engine. Use BEFORE writing the feature code, and when finishing or removing a rollout.

日本語の概要は準備中です。原文の説明を表示しています。

different-ai/openwork2.4万2026年10月11日 更新

Local OpenWork Electron browser automation with CDP. Use when driving a local Electron dev app, browser_list, browser_snapshot, browser_eval, composer automation, or local UI smoke tests.

日本語の概要は準備中です。原文の説明を表示しています。

different-ai/openwork2.4万2026年10月11日 更新

Flag customer, prospect, partner, or outside-person identities in the diff. Reported in the Warden security summary.

日本語の概要は準備中です。原文の説明を表示しています。

different-ai/openwork2.4万2026年10月11日 更新

Connect the OpenWork MCP Gateway (https://api.openworklabs.com/mcp/agent) to Claude Code, Codex, Gemini CLI, Cursor, VS Code, Claude Desktop, or ChatGPT so the agent can use the user's OpenWork organization skills, plugins, and connections.

日本語の概要は準備中です。原文の説明を表示しています。

different-ai/openwork2.4万2026年10月11日 更新

Screen a pull request from an outside contributor for hidden, obfuscated, or supply-chain-risky changes before any of its code runs.

日本語の概要は準備中です。原文の説明を表示しています。

different-ai/openwork2.4万2026年10月11日 更新

Create an OpenCode plugin for OpenWork. Scaffolds the plugin file with the correct API shape, tool definitions, and hook registration. Use when the user asks to 'create a plugin', 'write a plugin', or 'make a plugin that does X'.

日本語の概要は準備中です。原文の説明を表示しています。

different-ai/openwork2.4万2026年10月11日 更新

different-ai のスキルをすべて見る

このスキルの問題を報告する