Repository navigation
service: cached Store pwsh path goes stale after package update #56381
Description
Summary
opencode's service resolves the user's shell once and then spawns every shell command with that exact absolute path. On Windows, a Microsoft Store PowerShell resolves to a versioned package directory such as C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe\pwsh.EXE. When the Store package updates and the versioned directory changes, the cached path stops existing and every opencode shell command fails until the service is restarted, which re-resolves the shell.
Environment
- opencode version: v2.0.27
- OS: Windows_NT 10.0.19045 (win32 x64)
- Terminal: TERM=xterm-256color, TERM_PROGRAM unset (Windows console)
- Shell: pwsh 7.6.6 from Microsoft Store at spawn time; ComSpec
C:\WINDOWS\system32\cmd.exe - Install/channel: latest
- Active plugins: none configured (one local MCP server
reain~/.config/opencode/opencode.json)
Reproduction
- On Windows, have PowerShell installed from the Microsoft Store, so an opencode session spawns pwsh from the versioned package path (for example
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe\pwsh.EXE). - Let the Store update the PowerShell package so the old versioned directory is replaced.
- In the still-running opencode service, run any command through the shell tool.
Expected Behavior
When the cached shell path no longer exists, the service should re-resolve the current pwsh path (or fall back to re-discovery) instead of failing every command.
Actual Behavior
The service kept spawning the obsolete Microsoft.PowerShell_7.6.6.0 package path. In ~/.local/share/opencode/log/opencode.log, 440 spawns used that Store package path, the last at 2026-10-17T06:34:41Z. After opencode service restart, the first spawn at 2026-10-17T06:45:54Z used C:\Program Files\PowerShell\7\pwsh.EXE, and all shell commands worked again.
Additional Context
- The failure appeared after the Store updated PowerShell (7.6.6) during a running session, so the versioned
Microsoft.PowerShell_7.6.6.0_...directory referenced by the service went stale. - Workaround that fixed it:
opencode service restart. - Frequency: observed once; it should recur whenever a Store-managed shell updates while the service is running.
Activity
opencode-agent commentedon Oct 17, 2026
Thanks for the clear report, and for pinning down the trigger. I think this is a duplicate of #55733.
In both cases, when no
shellis configured, the service picks a shell once (resolve()inpackages/core/src/shell/select.ts) and saves it for as long as the service runs. Nothing checks later whether that path still exists. So when the Store update removedMicrosoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe, every spawn kept using the missing path until the restart. #55733 shows the same symptom (Windows, pwsh 7.6.6, background service, every shell command failing until a restart), but its cause was still unknown. Your Store-update finding is very likely that missing cause, so it would really help to add it there.Possible duplicates and related issues, ordered by likelihood:
pwsh(app-execution alias) is not resolved and silently falls back to Windows PowerShell 5.1.Workaround until this is fixed: set
"shell"to an absolute path in your globalopencode.json, e.g."shell": "C:\\Program Files\\PowerShell\\7\\pwsh.exe". A configured shell isn't saved this way, so a Store update won't break it, and the change takes effect without restarting.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
Hayston1001 commentedon Oct 18, 2026
Where the cached path can come from, measured on Windows 11 with Store
pwsh7.6.7:pwshchild,$PSHOMEisC:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.7.0_x64__8wekyb3d8bbwe.ProcessPATH carries%LOCALAPPDATA%\Microsoft\WindowsApps\Microsoft.PowerShell_8wekyb3d8bbwe, which holds anotherpwsh.exethat is also a 0-byte alias.%LOCALAPPDATA%\Microsoft\WindowsApps\pwsh.exefailstatSyncwith EACCES, whileaccessSync(X_OK)succeeds and CreateProcess launches them.So the versioned folder can enter the environment opencode inherits from the shell it probes, be resolved once into an absolute path, and then be reused. On 7.6.6 the PATH entry looks like it was the versioned folder itself, which is exactly the path in the failing spawn log.
Revalidating the cached path when its folder is gone, or re-resolving instead of keeping an absolute string, would cover this case.
opencode-agent commentedon Oct 18, 2026
Closing this as a duplicate of #55733, since we haven't heard back in the day since the duplicate note. The problem is the same: when no
shellis configured, the service saves the shell it found at startup and never checks it again. Once that path stops existing, every shell command fails until the service restarts.You found what likely triggers it: a Microsoft Store PowerShell update removing the versioned
WindowsApps\Microsoft.PowerShell_7.6.6.0_...folder. #55733 doesn't have that yet, so please add it there, ideally with the log line showing the stale path.Until it's fixed, you can set
"shell"to an absolute path such asC:\\Program Files\\PowerShell\\7\\pwsh.exein your globalopencode.json. A configured shell isn't saved this way, so Store updates won't break it.If this turns out to be a different problem, reply here and we can reopen it. Thanks for the detailed report!