Repository navigation
OpenCode uses Windows PowerShell 5.1 instead of the PowerShell 7 it was launched from #17372
Closed as not planned
Description
Description
Description:
OpenCode is launched from PowerShell 7 (pwsh), but when executing bash commands, it uses C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe (PowerShell 5.1) instead of PowerShell 7.
Impact:
- PowerShell 7 profile is not loaded
- Environment variables, aliases, and functions configured in PowerShell 7 are unavailable
- Developers who have migrated to PowerShell 7 cannot use their familiar configuration
Expected Behavior:
OpenCode should use the same PowerShell version it was launched from, or at least prefer the newer PowerShell version installed on the system.
Environment:
- Windows
- PowerShell 7.5.4 installed
- OpenCode launched from pwsh
Plugins
No response
OpenCode version
1.2.24
Steps to reproduce
- Launch OpenCode from PowerShell 7 (pwsh)
- Execute a bash command in OpenCode
- The command runs in PowerShell 5.1 environment instead
Screenshot and/or share link
No response
Operating System
Windows 11
Terminal
PowerShell 7.5.4 installed
Reacted by Patrick Matthiesen, Zeldris, satoshi_hojo, Ruan Galli, Faisal Afroz and Flemming Steffensen
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Mar 13, 2026
This issue might be a duplicate of existing issues. Please check:
Please review these issues to see if your report is already covered or if your specific case (bug: using PS 5.1 instead of the PS 7 it was launched from) is distinct enough to warrant a separate issue.
Mart-Bogdan commentedon May 17, 2026
LOL. for me it is in reverse. I've launchef it from 5.1, but OpenCode usese 7.5
kcorax commentedon Jun 29, 2026
It’s very likely that your PATH places Windows PowerShell (powershell.exe) ahead of your modern PowerShell (pwsh.exe) installation. I’ve seen this exact issue on other systems, and the combination of PATH order plus installation type is usually the culprit.
Winget no longer installs a real standalone package — it redirects you to the Store/MSIX version of PowerShell. That build is sandboxed and relies on shims. Removing it and installing the MSI distribution (explicitly the ~200 MB MSI — not MSIX, not MSIXBundle) consistently fixes the problem.
The Store/MSIX version installs shims that can launch modern PowerShell, but they do not cover the canonical path: %ProgramFiles%\PowerShell\7\pwsh.exe
A lot of applications are hardcoded to look exactly there. Notice the executable is pwsh.exe, not
powershell.exe. The shims shadowpowershell.exeand thepowershellalias, but the correct modern binary is alwayspwsh. Depending on whether you installed via Store or MSI, the alias/executable mapping flips — which is why this feels chaotic.Also, don’t worry about updates: the official MSI installation is serviced automatically. On Windows, Windows Update handles it; on other platforms, the runtime’s own updater takes care of it.
kcorax commentedon Jun 29, 2026
Now on the not so relevant issue that was folded into this for whatever reason, about the shell tool being called whatever, I mean, we are still developers. Wrap your powershell in a custom tool and asign it to whichever agent you like. In fact make a new powershell developer agent, plug it with some 7.6 latest changes, give it the miscrosoft learn mcp too (it's actually excellent) and you should be happier than default. Definitely more resilient against context compaction events. Oh and for agent personality all you'll need it "in case a problem arises and you can't solve it by consulting the learn mcp OR in case you fuck up, explain the problem in a concise manner, list the outpup that indicates something went wrong and HALT".
github-actions commentedon Aug 28, 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.
Mart-Bogdan commentedon Aug 29, 2026
Oh my god, WHY???