skill tool fails with EUNKNOWN: unknown error, uv_spawn when PowerShell is denied by policy (Windows) #52306

Description

EUNKNOWN: unknown error, uv_spawn when loading any skill (including with --pure) on a Windows machine where PowerShell execution is denied by Group Policy / AppLocker. cmd.exe and direct file reads work fine — only skill loading fails.

Root cause (found in source)

• packages/opencode/src/tool/skill.ts — the skill tool calls ripgrep.find({ cwd: dir, ... }) to list the skill's files every time a skill is loaded.
• packages/core/src/ripgrep/binary.ts — RipgrepBinary.Service.filepath resolves the rg binary by: (1) checking which("rg.exe") on PATH, (2) checking a cached copy, (3) downloading ripgrep-<version>-<arch>-pc-windows-msvc.zip from GitHub and extracting it.
• On Windows, the .zip extraction path is hardcoded to PowerShell, with no fallback:

if (config.extension === "zip") {
  const shell = (yield* Effect.sync(() => which("powershell.exe") ?? which("pwsh.exe"))) ?? "powershell.exe"
  const result = yield* run(shell, [
    "-NoProfile", "-NonInteractive", "-Command",
    `$global:ProgressPreference = 'SilentlyContinue'; Expand-Archive -LiteralPath '${archive}' -DestinationPath '${dir}' -Force`,
  ])
  ...
}

On a machine where PowerShell execution is denied by policy, which("powershell.exe") still resolves the binary (it's present on disk and on PATH — the policy denies execution, not presence), so the code proceeds to spawn it. Windows then rejects the CreateProcess call at the OS level (observed message: "This program is blocked by group policy"). That rejection surfaces as an unclassified/unknown error to libuv — hence EUNKNOWN: unknown error, uv_spawn instead of a more legible permission error.

Windows ships tar.exe natively (used for .tar.gz on other platforms in the same file), which can extract .zip archives too and is not subject to the PowerShell policy restriction. Using tar (or falling back to it when PowerShell isn't available/executable) instead of Expand-Archive for the Windows .zip case would avoid this failure mode entirely.

Reproduced

On a Windows 11 VM with an AppLocker policy that denies powershell.exe/pwsh.exe/powershell_ise.exe execution for a specific user (everything else allowed):

> where powershell.exe
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

> powershell.exe -NoProfile -NonInteractive -Command "Write-Host hello"
This program is blocked by a group policy. For more information, contact your system administrator.

opencode's .cache\opencode\bin\ directory on that account contained a downloaded-but-never-extracted ripgrep-15.1.0-aarch64-pc-windows-msvc.zip, re-downloaded on every session (extraction silently failing each time, never producing rg.exe).

Manually extracting the same zip with tar -xf ripgrep-....zip -C <dir> works without issue on the same account, confirming tar is not affected by the policy that blocks PowerShell.

Workaround

Place a working rg.exe somewhere already on PATH — RipgrepBinary.filepath checks which("rg.exe") first and skips the download/extract path entirely if found.

OpenCode version

Observed on 1.18.25 and reported independently on 1.18.33; the relevant code (packages/core/src/ripgrep/binary.ts) is unchanged between those versions (last touched 2026-06-30).

Operating System

Windows 11 (reproduced on ARM64; the extraction mechanism itself is architecture-independent — any Windows machine with PowerShell execution denied by policy should hit this)

Terminal

cmd.exe / non-interactive (scheduled task)