Repository navigation
[Bug] WSL terminals spawned by Buzz (Windows) #2328
Description
Describe the bug
Rather incessant and annoying WSL terminals spawning after installing Buzz via Codex.
To Reproduce:
Steps to reproduce the behavior:
- Install Buzz via .exe
- Install codex via npm
- Install acp layer via npm
- Enter Buzz app
- Do anything.
Expected behavior:
I expect no terminal spam :(
Supporting Material
n/a
Environment (please complete the following information):
- OS: Win11
- 0.4.22
Additional context
My Hermes agent seems to suspect it's a problem with the ACP layer. I'm going to try installing on WSL to see if the issue goes away.
Activity
keshav0479 commentedon Jul 22, 2026
I’m seeing the same thing on Windows 11 with Buzz 0.4.22.
During onboarding, “Finding your providers…” took around five minutes and opened a Windows/WSL terminal. After Buzz finally detected Claude Code and Codex, installing the Codex adapter also took several minutes and ended with “Installation failed.”
I looked into what Buzz was launching and it seems to be picking:
%LOCALAPPDATA%\Microsoft\WindowsApps\bash.exeinstead of the actual Git Bash installed here:
C:\Program Files\Git\bin\bash.exeThe WindowsApps version is a WSL launcher, not Git Bash. On my machine, running the same lookup through that Bash did not finish within 15 seconds. Running it through the real Git Bash finished in about 0.5–0.7 seconds. Even
wsl.exe --statuswas still stuck after 10 seconds.From the code, Buzz searches PATH for any
bash.exebefore trying to locate Bash from the Git installation. It also repeats shell lookups when commands are missing. That seems to explain the long provider scan. The installer uses the same Bash resolution and has a five-minute timeout, which also lines up with the Codex installation failure.I checked PR #2247 as well. It adds hidden-window handling and improves the install PATH, but it doesn’t change
managed_agents/git_bash.rs. So the WSL process may become hidden while Buzz still selects it and waits.It looks like Buzz should ignore the WindowsApps/WSL Bash alias and prefer the Bash that belongs to Git for Windows. It would also be good to add a test for this PATH ordering case so the problem doesn’t come back.
fix(windows): prefer Git Bash over WindowsApps bash alias
fix(windows): prefer Git Bash over WindowsApps bash alias