Windows: bash tool shell is compiled in (cmd.exe /D /S /C); make it configurable so Git Bash can be used

Summary

On Windows, the built-in bash tool always spawns cmd.exe /D /S /C "<command>", and the shell is selected at compile time. There is no config key and no environment variable to route commands through Git Bash (or any other shell), so anyone whose project tooling is POSIX-based has to hand-roll a wrapper on every call.

Related, but not the same: #1254 (a dedicated PowerShell tool next to the cmd.exe branch) and #630 (configurable shell for ! commands). This issue is specifically about making the existing bash tool's shell selectable.

Environment

• Windows 11 x64
• jcode v0.84.0 (57d587899), prebuilt release binary

Evidence that the shell is compiled in

Scanning the release binary for the shell entry point:

• the only shell-spawning strings are cmd.exe + /D + /S + /C, emitted from crates/jcode-app-core/src/tool/ (see the BashInput description string: "Run a Windows cmd.exe command (compatibility name bash). Use cmd.exe syntax, not Bash.").
• COMSPEC has 0 occurrences, so the standard Windows mechanism for overriding the command interpreter is not consulted.
• a hypothetical JCODE_SHELL / shell_path / default_shell config key has 0 occurrences, and jcode --help exposes no shell option.

Impact

1. Every POSIX command has to be manually wrapped, e.g. "C:\Program Files\Git\bin\bash.exe" -lc "<command>", in every tool call, and it must be re-discovered by each new session.
2. Quoting is fragile because the outer cmd.exe both expands %VAR% and parses the whole line before bash sees it:
   • %PATH% is expanded by cmd.exe, so only bash's ${PATH} form is safe.
   • ; and , are token separators to cmd.exe, so a bash command that relies on ; inside cmd-visible quoting can be split into multiple arguments (observed: bash -lc 'echo a; ls' mangled to tr: extra operand).
   • a command whose final character is a quote can desynchronise cmd.exe's quote pairing.
3. Output/exit-code behaviour is otherwise fine, so this is purely a shell-selection gap.

Suggested fix

Any one of:

• a config knob, e.g. [tools] shell_path = "C:\\Program Files\\Git\\bin\\bash.exe" or shell = "cmd" | "pwsh" | "git-bash", applied as <shell> <args> -c "<command>";
• a JCODE_SHELL env override;
• auto-detect and prefer Git Bash when bash.exe is present, falling back to cmd.exe (this also removes the POSIX-quoting hazard for those users).

A related nicety: when a POSIX shell is selected, the tool description shown to the model should switch from "cmd.exe syntax" to bash semantics, since that text currently misleads the agent.

Workaround currently in use

A one-line forwarder on PATH (jb.cmd):

@echo off
setlocal enableextensions
set "GITBASH=C:\Program Files\Git\bin\bash.exe"
if not exist "%GITBASH%" set "GITBASH=C:\Program Files\Git\usr\bin\bash.exe"
"%GITBASH%" --login -c %*
exit /b %ERRORLEVEL%

Called as jb "<bash command>", this preserves the working directory and propagates exit codes (verified for 0/1/7/127), but it only fixes the shell, not the underlying cmd.exe quoting layer, and it must be recreated on every machine.

Start in crates/jcode-app-core/src/tool/ and locate the existing BashInput implementation and its Windows cmd.exe spawning path. Read nearby configuration and environment-override patterns before choosing how shell selection should be represented. Done means the existing bash tool can select a configured shell without the cmd.exe quoting layer, and its displayed syntax description matches the selected shell.