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
What shell is used on Windows power shell when doing a bash toolcall? #5557
To me as a user it seems it sometimes uses WSL2 to execute a bash command and sometimes it uses the power shell instance that I start opencode with. I know it's recommended to run opencode in a bash capable environment but for now it's more convenient for me to use powershell.
So what determines what shell is called? I instruct my agent to use power shell commands but sometimes it ends up in WSL2 and vice versa. So what is happening under the hood and how can I make sure the agent will always use one shell and not the other? The tool call is called bash which is confusing for the agent as well. If the tool would be called shell, it can be power shell as well as bash.
Both issues discuss similar shell selection behavior on Windows where the wrong shell environment is used. Feel free to ignore if your specific case differs from these.
Thanks, I more or less understand now how it works. If bun.file(bash).size fails somehow it'll pick cmd.exe, if not it'll pick git bash. The disadvantage of git bash is that it doesn't have a package manager to install more stuff (This can of course be done in powershell more or less. When the LLM tries to run certain commands I sometimes try to intstall them). Then it's unclear when it fails or succeeds, it can be a bit random, sometimes it picks this, or that.
I've now configured SHELL and set to git bash and now it's more consistent. I still need to instruct some LLMs (mostly local Qwen3 30B A3B 2507 Q6_K_XL) to use platform independent paths (ie forward slashes) or stuff goes south.
Most LLMs assume full Linux bash so if you do implement powershell I'm not sure it'll solve the issue entirely. I've tried a custom version of msys2 but it's a bit slow to start and it doesn't appear to run any commands, but it does have a package manager to install stuff. Could be an option if it can be made to work. Maybe it can be spawned once and reused for followup commands instead of just creating and killing the process every time. Starting up shells in rapid succession can be quite resource intensive.
Activity
github-actions commentedon Dec 15, 2025
This issue might be a duplicate of existing issues. Please check:
Both issues discuss similar shell selection behavior on Windows where the wrong shell environment is used. Feel free to ignore if your specific case differs from these.
rekram1-node commentedon Dec 15, 2025
This file kinda covers how it works, and believe me i know it's POOR:
https://github.com/sst/opencode/blob/c3b3b133b0b405a4cad700e57194620f653ee215/packages/opencode/src/shell/shell.ts#L39
We are going to add a powershell tool that will be provided to agent instead of bash tool if your shell is powershell.
We use git bash rn as a bandaid if we can find it
imqqmi commentedon Dec 21, 2025
Thanks, I more or less understand now how it works. If bun.file(bash).size fails somehow it'll pick cmd.exe, if not it'll pick git bash. The disadvantage of git bash is that it doesn't have a package manager to install more stuff (This can of course be done in powershell more or less. When the LLM tries to run certain commands I sometimes try to intstall them). Then it's unclear when it fails or succeeds, it can be a bit random, sometimes it picks this, or that.
I've now configured SHELL and set to git bash and now it's more consistent. I still need to instruct some LLMs (mostly local Qwen3 30B A3B 2507 Q6_K_XL) to use platform independent paths (ie forward slashes) or stuff goes south.
Most LLMs assume full Linux bash so if you do implement powershell I'm not sure it'll solve the issue entirely. I've tried a custom version of msys2 but it's a bit slow to start and it doesn't appear to run any commands, but it does have a package manager to install stuff. Could be an option if it can be made to work. Maybe it can be spawned once and reused for followup commands instead of just creating and killing the process every time. Starting up shells in rapid succession can be quite resource intensive.