Grep tool fails on Windows: ripgrep extraction broken by MSIX PowerShell 7 PSModulePath, and failures are cached until restart #40623

Activity

1. github-actions

   assigned

   Hona

   on Aug 5, 2026
2. github-actions commented on Aug 5, 2026

   

   github-actionsBot

   on Aug 5, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Bug: Expand-Archive module auto-load fails when spawned from opencode.exe (Bun) #24291: Same root cause — Expand-Archive fails when spawned from opencode.exe (Bun) on Windows, module auto-load error (open)
   • Expand-Archive error on Windows PowerShell when loading skills in v1.14.18 #23457: Same symptom — Expand-Archive error on Windows PowerShell when loading skills (closed)
3. luckducks commented on Aug 5, 2026

   

   luckducks

   on Aug 5, 2026

   Author

   More actions

   Workarounds (confirmed working on the affected machine)

   Quick fix — make opencode find rg.exe without downloading:

   opencode resolves ripgrep in this order: which("rg.exe") → <Global.Path.bin>/rg.exe → download from GitHub (packages/core/src/ripgrep/binary.ts). On Windows, Global.Path.bin is %USERPROFILE%\.cache\opencode\bin\. So:

   1. Download ripgrep for Windows: gh release download 15.1.0 --repo BurntSushi/ripgrep --pattern "ripgrep-15.1.0-x86_64-pc-windows-msvc.zip"
   2. Extract it and copy rg.exe to %USERPROFILE%\.cache\opencode\bin\rg.exe (create the directory if needed)
   3. Restart opencode — required because of Bug 2 (the failed resolution is cached in the process; only a fresh process will pick up the binary)

   Root-cause fix — fix the PowerShell module resolution:

   The failure only happens because Windows PowerShell 5.1 inherits the MSIX PowerShell 7 session's PSModulePath, which lists the Store package's $PSHOME\Modules (Core-only modules) before C:\Windows\system32\WindowsPowerShell\v1.0\Modules\. The 5.1 autoloader stops at the first incompatible (Core-only) match and reports CouldNotAutoloadMatchingModule instead of continuing the search.

   Options:

   • Recommended: uninstall the Microsoft Store (MSIX) version of PowerShell 7 and install the official MSI distribution instead (same consensus as OpenCode uses Windows PowerShell 5.1 instead of the PowerShell 7 it was launched from #17372 and 无法使用shell #20603). MSI PowerShell 7 keeps C:\Program Files\PowerShell\7\ out of the 5.1 module-search collision and is serviced by Windows Update.
   • Alternatively, launch opencode from Windows PowerShell 5.1 or from a terminal that does not put the MSIX pwsh package dir ahead of system32\WindowsPowerShell\v1.0\Modules\ in PSModulePath.

   Verification:

   • rg.exe alone fixes grep/glob permanently — confirmed on the affected machine after restart (headless opencode run returned 64 matches; in-session grep returned 18 matches).
   • The node repro confirmed the env dependence: spawning 5.1 with the full MSIX-inherited PSModulePath reproduces the exact CouldNotAutoloadMatchingModule error; removing/overriding PSModulePath makes extraction succeed.
4. Yuxin-Qiao

   added a commit that references this issue on Aug 7, 2026

   fix(core): retry failed ripgrep resolution and sanitize PowerShell 5.…

   ...

   994d6b6
5. MilkyWay008 commented on Aug 17, 2026

   

   MilkyWay008

   on Aug 17, 2026

   More actions

   Two real bugs in one. The PowerShell-7-only Microsoft.PowerShell.Archive getting picked first is the autoloader doing exactly what the docs say it'll do...... it stops at the first compatible-looking match and never falls back to System32. Fix for that: strip the MSIX $PSHOME\Modules from PSModulePath before opencode spawns 5.1 (Expand-Archive's real home), or just launch opencode from a non-MSIX shell. Bug 2 is rougher...... Effect.cached wrapping a failing effect is a 'never retry until restart' footgun, and that's basically the contract nobody wants from a tool resolver. Until that's patched, the workaround you posted (drop rg.exe into ~/.cache/opencode/bin + restart) is what works. Oh also, btw, I built a portable Hermes OTG and I keep it on USB for the 'every Grep call retries the same broken download' days...... imo, side-by-side agent helps you keep diagnosing while the upstream fix lands. https://github.com/MilkyWay008/Hermes-OTG
6. Y545329005 commented on Oct 11, 2026

   

   Y545329005

   on Oct 11, 2026

   More actions

   Additional confirmation from a Windows 11 machine, including a source-check that may help pin this down.

   Environment: opencode 1.19.0 (CLI, scoop), Windows 11, PowerShell 7.6.6 installed via Microsoft Store (MSIX), opencode launched from the MSIX pwsh session.

   Symptom (matches exactly): grep/glob/skill all fail with CouldNotAutoloadMatchingModule. The zip ripgrep-15.1.0-x86_64-pc-windows-msvc.zip is downloaded on every new run (observed 10-02, 10-03, 10-05, 10-06 x2, 10-08, 10-10, 10-11) into ~/.cache/opencode/bin/ but rg.exe is never extracted.

   Source check (main today): packages/core/src/ripgrep/binary.ts still selects the extraction shell as
   findExecutable("powershell.exe") ?? findExecutable("pwsh.exe"), i.e. it prefers Windows PowerShell 5.1 even when a pwsh is available — so this is not fixed by the shell setting in config. The child is spawned with extendEnv: true, which is what carries the MSIX PSModulePath through.

   A detail that may help: I could not reproduce the failure from outside opencode. Spawning powershell.exe from a pwsh parent (even with PSModulePath explicitly set to the MSIX-ordered 5-entry list) always worked — 5.1 recomputes PSModulePath on startup in that path. The failure only happens when the process is spawned the way Bun does it with extendEnv: true. So the difference appears to be the spawn/env mechanism, not the PSModulePath value itself.

   Workaround that actually fixed it: which("rg.exe") is consulted before download (resolution order: PATH -> Global.Path.bin -> download). Installing ripgrep so that rg.exe is on PATH (scoop install ripgrep -> shims/rg.exe) resolves it — the download/extract path is never entered. Also confirms Bug 2: a fresh process is required (the failure is cached in-process until restart). Separately, manually placing rg.exe in ~/.cache/opencode/bin/ did not stick — opencode's own install/cleanup path removed it.

   Happy to provide logs if useful.

   Environment note: machine registry PSModulePath (HKLM) does not contain the WindowsApps dir; the MSIX dirs are injected into the session env by the Store pwsh at startup.
7. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
8. thdxr

   closed this as not plannedon Oct 11, 2026