You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Expand-Archive error on Windows PowerShell when loading skills in v1.14.18 #23457
When loading any skill on opencode CLI on Windows powershell, the skill fails to load do to an Expand-Archive error. (any agent run grep operation will also do the same)
Expand-Archive : Cannot validate argument on parameter 'LiteralPath'. The argument is null or empty. Provide an
argument that is not null or empty, and then try the command again.
At line:1 char:29
Likely cause .... SkillTool calls rg.files(...) when loading a skill (packages/opencode/src/tool/skill.ts, line ~43).
In v1.14.18, ripgrep resolution now does:
find system rg, else
download ripgrep zip/tarball,
extract it,
cache binary.
On Windows zip extraction now runs:
powershell.exe -NoProfile -Command "Expand-Archive -LiteralPath $args[0] -DestinationPath $args[1] -Force"
(from packages/opencode/src/file/ripgrep.ts, around line 258)
***Temporary Workaround ***
Installing ripgrep beforehand resolves the error (winget install BurntSushi.ripgrep.MSVC)
Plugins
No response
OpenCode version
1.14.18
Steps to reproduce
Using v1.14.18 on windows powershell request the agent load any skill.
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
Windows Terminal
Reacted by KIRILL GOLIKOV, ballchen93, pubiqq and weeix
Root cause: PowerShell's -Command parameter doesn't reliably populate $args from trailing positional arguments — especially in Windows PowerShell 5.x. The archive and dir strings are passed after the -Command string at line 258 of ripgrep.ts, but $args[0] evaluates to null.
Fix: Inline the archive and destination paths directly into the PowerShell command string (with proper single-quote escaping) instead of relying on $args.
Sorry to hear it's still broken @asertym. Is this with v1.14.18 specifically, or a later version? I'll look into submitting a fix — the PowerShell $args handling definitely needs a different approach for Windows PowerShell 5.x.
@kagura-agent problem persists with v1.14.18 and v1.14.19 as well. Since the problem wasn't fixed between these versions, im thinking it was a change made from v1.14.17 to v1.14.18 that results in these issues appearing. Note that calling @filename also does not work, it returns no files found, which may be related to the same powershell issues.
Activity
kagura-chen commentedon Apr 20, 2026
I'd like to work on this.
Root cause: PowerShell's
-Commandparameter doesn't reliably populate$argsfrom trailing positional arguments — especially in Windows PowerShell 5.x. Thearchiveanddirstrings are passed after the-Commandstring at line 258 ofripgrep.ts, but$args[0]evaluates to null.Fix: Inline the archive and destination paths directly into the PowerShell command string (with proper single-quote escaping) instead of relying on
$args.fix(ripgrep): inline paths in PowerShell Expand-Archive command
asertym commentedon Apr 20, 2026
Still an issue unfortunately. Forced to downgrade to 1.14.17.
kagura-chen commentedon Apr 20, 2026
Sorry to hear it's still broken @asertym. Is this with v1.14.18 specifically, or a later version? I'll look into submitting a fix — the PowerShell
$argshandling definitely needs a different approach for Windows PowerShell 5.x.asertym commentedon Apr 20, 2026
@kagura-agent problem persists with v1.14.18 and v1.14.19 as well. Since the problem wasn't fixed between these versions, im thinking it was a change made from v1.14.17 to v1.14.18 that results in these issues appearing. Note that calling
@filenamealso does not work, it returns no files found, which may be related to the same powershell issues.Hona commentedon Apr 21, 2026
are you certain this is not working on v1.14.19?
can you please share the logs
chenxch commentedon May 13, 2026
When I rolled back to version 1.14.17, the problem persisted.
github-actions commentedon Jul 13, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.