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
On Windows, shell auto-detection derives a Git Bash path from Bun.which("git"), but currently treats git.exe as a directory when building the bash.exe path. This can cause Opencode to fall back to cmd.exe even when Git Bash is installed.
Plugins
N/A
OpenCode version
dev (local checkout @ 213c0e18a, package packages/opencode v1.1.36)
Steps to reproduce
Windows with Git for Windows installed (git available on PATH)
Ensure SHELL is unset and OPENCODE_GIT_BASH_PATH is unset
Trigger the bash tool (any tool call that uses Shell.acceptable())
Observe the selected shell path: it may not resolve to the actual Git Bash binary.
Operating System
Windows 11
Terminal
Windows Terminal
Expected
If git.exe is found (e.g. ...\\Git\\cmd\\git.exe), Opencode should derive Git Bash from path.dirname(git) (e.g. ...\\Git\\bin\\bash.exe).
Actual
The derived path may be built from path.join(git, "..", "..", "bin", "bash.exe"), which treats git.exe as a directory and can produce an invalid bash.exe path.
The core issue of Git Bash path auto-detection on Windows may share root causes with these other Windows shell detection problems. Feel free to ignore if this specific case differs from those issues.
Thanks! Agreed they’re related to Windows shell handling, but this one is a distinct bug in Shell.fallback() path construction: it treats the git.exefile path as a directory when deriving bash.exe, which can yield an invalid Git Bash path and force fallback to a non-bash shell.
I opened PR #10873 with a 1-line fix (path.dirname(git) before joining).
Git Bash in Windows defaults to opencode, causing command and environment errors. It should use PowerShell instead. Currently, the only workaround is to delete bash.exe to mitigate the issue. Additionally, when using bash, there are cases where it creates undeletable nul files in Windows.
Thanks for the context — I agree there are broader Windows+Git Bash edge cases.
This issue/PR (#10873) is narrowly fixing the incorrect Git Bash path derivation (treating git.exe as a directory). It shouldn’t change the overall default shell preference policy.
If the preferred behavior on Windows is to default to PowerShell even when Git Bash is present, that sounds like a separate design decision/issue. Likewise, the “undeletable NUL files” sounds like a separate (and potentially serious) bug; could you share a minimal repro (exact command, working directory, and where the nul file appears)?
In the meantime, users can force PowerShell by setting SHELL (or OPENCODE_GIT_BASH_PATH / OPENCODE_GIT_BASH_PATH-style overrides) so Opencode doesn’t pick Git Bash.
Thanks for the context — I agree there are broader Windows+Git Bash edge cases.
This issue/PR (#10873) is narrowly fixing the incorrect Git Bash path derivation (treating git.exe as a directory). It shouldn’t change the overall default shell preference policy.
If the preferred behavior on Windows is to default to PowerShell even when Git Bash is present, that sounds like a separate design decision/issue. Likewise, the “undeletable NUL files” sounds like a separate (and potentially serious) bug; could you share a minimal repro (exact command, working directory, and where the nul file appears)?
In the meantime, users can force PowerShell by setting SHELL (or OPENCODE_GIT_BASH_PATH / OPENCODE_GIT_BASH_PATH-style overrides) so Opencode doesn’t pick Git Bash.
Thank you for your quick response. I will try configuring the shell using environment variables.
Regarding the undeletable nul files, I don't think this is an isolated incident in the Windows environment — I've encountered it twice. The solution I found was to navigate to the directory via WSL and delete the files. This is also one of the main reasons pushing me to switch away from the Git Bash terminal.
Activity
github-actions commentedon Jan 27, 2026
This issue might be a duplicate of existing issues or closely related to shell detection on Windows. Please check:
The core issue of Git Bash path auto-detection on Windows may share root causes with these other Windows shell detection problems. Feel free to ignore if this specific case differs from those issues.
MaxMiksa commentedon Jan 27, 2026
Thanks! Agreed they’re related to Windows shell handling, but this one is a distinct bug in
Shell.fallback()path construction: it treats thegit.exefile path as a directory when derivingbash.exe, which can yield an invalid Git Bash path and force fallback to a non-bash shell.I opened PR #10873 with a 1-line fix (
path.dirname(git)before joining).AreChen commentedon Jan 28, 2026
Git Bash in Windows defaults to opencode, causing command and environment errors. It should use PowerShell instead. Currently, the only workaround is to delete bash.exe to mitigate the issue. Additionally, when using bash, there are cases where it creates undeletable nul files in Windows.
MaxMiksa commentedon Jan 28, 2026
Thanks for the context — I agree there are broader Windows+Git Bash edge cases.
This issue/PR (#10873) is narrowly fixing the incorrect Git Bash path derivation (treating
git.exeas a directory). It shouldn’t change the overall default shell preference policy.If the preferred behavior on Windows is to default to PowerShell even when Git Bash is present, that sounds like a separate design decision/issue. Likewise, the “undeletable NUL files” sounds like a separate (and potentially serious) bug; could you share a minimal repro (exact command, working directory, and where the
nulfile appears)?In the meantime, users can force PowerShell by setting
SHELL(orOPENCODE_GIT_BASH_PATH/OPENCODE_GIT_BASH_PATH-style overrides) so Opencode doesn’t pick Git Bash.AreChen commentedon Jan 28, 2026
Thank you for your quick response. I will try configuring the shell using environment variables.
Regarding the undeletable nul files, I don't think this is an isolated incident in the Windows environment — I've encountered it twice. The solution I found was to navigate to the directory via WSL and delete the files. This is also one of the main reasons pushing me to switch away from the Git Bash terminal.
pschiel commentedon Jan 28, 2026
advise to use
OPENCODE_GIT_BASH_PATHall other path issues concerning
path.joinwould be resolved via #6763GTonehour commentedon Feb 12, 2026
I just created #13369 for that issue.
github-actions commentedon Apr 14, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.