Bug: Expand-Archive module auto-load fails when spawned from opencode.exe (Bun)

[hui6900]

Description

Expand-Archive fails with "module could not be loaded" error when called internally by opencode.exe (Bun-compiled v1.14.24) on Windows.
The error occurs in tools like skill, glob (and any internal tool that calls Expand-Archive).

Error Message

Expand-Archive : The 'Expand-Archive' command was found in the module 'Microsoft.PowerShell.Archive',
but the module could not be loaded. For more information, run 'Import-Module Microsoft.PowerShell.Archive'.

Environment

• OS: Windows (win32)
• Shell: PowerShell 7.6.1
• opencode version: 1.14.24
• Node.js version: 24.15.0
• Binary: opencode-windows-x64 (Bun v1.3.13)

Investigation

The internal call is:
powershell -NoProfile -NonInteractive -Command
"$global:ProgressPreference = 'SilentlyContinue'; Expand-Archive -LiteralPath ..."
Confirmed working scenarios:

• pwsh -NoProfile -NonInteractive ✅
• powershell.exe -NoProfile -NonInteractive ✅
• Node.js child_process.spawnSync ✅
• Import-Module Microsoft.PowerShell.Archive -Force ✅
  Module file is intact, PSModulePath is correct, no Zone.Identifier blocking, not an ExecutionPolicy issue.
  Fails only when spawned from opencode.exe (Bun-compiled binary). Likely a Bun child_process environment compatibility issue on Windows.

Workaround

SKILL.md files can be read directly via the read tool, bypassing the skill loading tool.

Expected Behavior

Expand-Archive should work when called internally, same as it does from any normal PowerShell session.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Expand-Archive error on Windows PowerShell when loading skills in v1.14.18 #23457: Same Expand-Archive failure when loading skills on Windows via opencode — that issue identified the root cause as ripgrep extraction running powershell.exe -NoProfile -Command "Expand-Archive ..." from a Bun-spawned process. The symptoms and environment closely match.

If your issue is specifically about a different aspect (e.g., a different error message or occurring in a different code path), please clarify how it differs from #23457 so maintainers can determine if this is a new distinct bug or a continuation of the same one.

[hui6900]

This is a different bug from #23457. #23457 fails with ParameterArgumentValidationError (null/empty -LiteralPath), while this one fails with CouldNotAutoloadMatchingModule — PowerShell can find the Expand-Archive command but fails to load the Microsoft.PowerShell.Archive module when spawned from the Bun-compiled binary. The module loads fine in all other scenarios (pwsh, powershell.exe, Node.js child_process). This is a module auto-load compatibility issue specific to Bun's process spawning on Windows.

[Snakeblack]

Confirmed still reproducing in opencode v1.14.31 (latest as of today).

Environment

• OS: Windows 10.0.26200 (Windows 11)
• Shell configured: C:\Program Files\PowerShell\7\pwsh.exe (PowerShell 7.6.1)
• opencode: v1.14.31

Symptoms

Error appears in stderr of internal tools — observed in glob, grep, and skill loading:

Expand-Archive : El comando 'Expand-Archive' se encontró en el módulo 'Microsoft.PowerShell.Archive',
pero el módulo no pudo cargarse.
+ ... lobal:ProgressPreference = 'SilentlyContinue'; Expand-Archive -Litera ...
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

Tools still return correct results — the error is cosmetic noise on stderr, not a functional failure. But it pollutes the TUI output significantly when many tool calls happen in sequence.

Confirms diagnosis from #24291

• Manual repro with powershell.exe -NoProfile -NonInteractive -Command "..." from a regular shell works fine (Archive module v1.0.1.0 system + v1.2.5 user-installed both autoload OK)
• Manual repro with pwsh.exe -NoProfile -NonInteractive -Command "..." also works fine
• Fails only when the spawn comes from the Bun-compiled opencode.exe runtime
• Custom "shell" setting in opencode.json does not affect internal tools (only the bash tool)

Suggested workaround for maintainers

Since the bug is in Bun's child_process env propagation on Windows, replacing Expand-Archive with a direct .NET call would sidestep the PowerShell module autoload entirely:

Add-Type -AssemblyName System.IO.Compression.FileSystem
[System.IO.Compression.ZipFile]::ExtractToDirectory($src, $dst)

This works in any PowerShell session regardless of module autoload state, and removes the dependency on Microsoft.PowerShell.Archive entirely.

[cumal]

Same problem here. Windows 11 using proweshell 7.6.1 and OC 1.15.10

My log:

explore this project and search for a boolean variable which controls the speed of the software.
+ Thought: 2.1s
I'll explore the codebase to find a boolean variable controlling software speed. Let me search systematically.
✱ Grep "\b(speed|fast|slow)\s*[=:]\s*(true|false)" 
Expand-Archive : The 'Expand-Archive' command was found in the module 'Microsoft.PowerShell.Archive', but the module 
could not be loaded. For more information, run 'Import-Module Microsoft.PowerShell.Archive'.
At line:1 char:50
+ ... lobal:ProgressPreference = 'SilentlyContinue'; Expand-Archive -Litera ...
+                                                    ~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Expand-Archive:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

[lostal]

Same here. v1.15.3, Win 11, PS 7.6.2. Error on every prompt, glob and grep are dead. Module loads fine from a terminal but fails when opencode's binary spawns it. Also leaves vscode-eslint.zip unextracted in ~/.local/share/opencode/bin/. Looks like a Bun child_process issue on Windows.