Codebuff's Windows bash detection strategy is fundamentally fragile

[anuxs]

Description: findWindowsBash() in sdk/src/tools/run-terminal-command.ts falls back to C:\Windows\System32\bash.exe (WSL bash) when Git Bash is not found. WSL bash outputs a UTF-16 LE encoded MOTD/startup message that corrupts ALL command output when decoded as UTF-8 by data.toString() .

In findWindowsBash() in sdk/src/tools/run-terminal-command.ts , added detection logic for Git Bash installed via the Scoop package manager.
What changed: Before falling back to PATH search, after checking the 3 hardcoded paths, added Scoop detection:
// typescript
// Detect SCOOP env var, fall back to C:\Users<user>\scoop
const scoopBase = env.SCOOP || path.join(os.homedir(), 'scoop')
const scoopGitDir = path.join(scoopBase, 'apps', 'git', 'current')
// Check both bin\bash.exe and usr\bin/bash.exe (varies by Git for Windows version)
const scoopCandidates = [
path.join(scoopGitDir, 'bin', 'bash.exe'),
path.join(scoopGitDir, 'usr', 'bin', 'bash.exe'),
]
for (const scoopBash of scoopCandidates) {
if (fs.existsSync(scoopBash)) {
return scoopBash
}
}
Problem fixed: For users who install Git via Scoop, Codebuff previously couldn't find bash.exe (since it wasn't in the 3 hardcoded paths), and fell back to WSL's System32\bash.exe . WSL bash emits a UTF-16 LE encoded MOTD on startup, which data.toString() decodes as UTF-8, producing garbled output that contaminates all terminal command output.
Workaround: If you don't want to wait for this PR to be merged, you can set the CODEBUFF_GIT_BASH_PATH environment variable to D:\Scoop\apps\git\current\bin\bash.exe to fix it immediately.

---

A deeper issue: Codebuff's Windows bash detection strategy is fundamentally fragile

I ran into this bug because Codebuff's findWindowsBash() found WSL's System32\bash.exe instead of Git Bash's bash.exe — and the result was UTF-16 LE encoded MOTD corrupting every terminal command. But the real problem goes beyond just missing a few package manager paths.

How competitors handle this

Claude Code and Hermes-Agent both bundle Git for Windows and use its bash.exe as their exclusive script execution environment. They deliberately do not use Windows native terminals (cmd/pwsh) or WSL bash. Why?

Tool	Strategy
Claude Code	Bundles Git for Windows → uses its bash.exe as the runtime. Known path, no encoding surprises.
Hermes-Agent	Same approach — Git Bash as the unified execution environment.
Cursor	Ships its own Node.js + bash runtime. Doesn't rely on the system at all.
Codebuff (current)	Searches PATH for any bash → finds whatever is available (WSL, Git Bash, or some other bash).

The findWindowsBash() fallback chain is:

hardcoded paths → PATH search → WSL bash (last resort!)

This approach has several design flaws:

1. It looks for "any bash", not "Git Bash specifically"

• WSL bash is treated as a valid fallback, but it has serious encoding issues (UTF-16 LE MOTD that data.toString() with default UTF-8 decoding garbles)
• The code comments even acknowledge this: // WSL can be unreliable (VM not running, quote escaping issues, UTF-16 encoding) — yet still uses it as fallback
• Git Bash (from Git for Windows) provides a consistent MSYS2 environment with UTF-8 encoding and a full Unix toolchain

2. Windows native terminals are not a reliable alternative

PowerShell alone has multiple compatibility problems:

• PowerShell 5 (Windows built-in) vs PowerShell 7 (pwsh) — different APIs, different behaviors
• cmd.exe lacks basic Unix commands (grep, sed, awk, etc.)
• Chinese encoding (cp936/GBK vs UTF-8) causes garbled text
• Behavior varies across Windows versions

3. The error message points users in the wrong direction

The current error message suggests three options:

1. Install Git for Windows
2. Use WSL
3. Set CODEBUFF_GIT_BASH_PATH

Options 2 (WSL) leads to the exact encoding problem described in this issue. Option 3 (env var) is a workaround, not a fix.

Suggested approach

The fix should shift from "find any bash on the system" to "ensure Git Bash is used for execution":

1. Short-term (already proposed): Add Scoop/Chocolatey paths to findWindowsBash() so more Git Bash installations are found correctly
2. Medium-term: Remove WSL bash from the fallback chain entirely. If Git Bash is not found, show a clear error message guiding the user to install Git for Windows or set CODEBUFF_GIT_BASH_PATH
3. Long-term: Consider bundling Git for Windows bash.exe with the Codebuff Windows installer, or at least providing an automated setup step during first launch

Git for Windows is already a ~50MB dependency that most developers on Windows already have. The key is to find it reliably and use it exclusively — not to fall back to incompatible alternatives like WSL or System32 bash.