Allow users to explicitly select Git Bash as the Bash tool shell on Windows

Problem

On Windows, Maka's Bash tool always resolves to PowerShell: detectShell() in packages/runtime/src/shell-detect.ts picks PowerShell 7 (pwsh), then Windows PowerShell 5.1, then cmd.exe as a last resort. There is no branch for Git Bash, and no way for a user to override the selection.

This is a problem for three groups of users:

• Users who already write Bash/POSIX on Windows (whether via Git Bash, MSYS2, or connecting to a WSL/remote backend) and whose muscle memory, shell dotfiles, and aliases are Bash-shaped. They are forced to translate every command into PowerShell syntax even though a capable Bash is installed.
• bash-style commands that a model emits from a Bash-centered prompt/SDK or from a project whose documented commands are POSIX-only fail or behave differently under PowerShell, which can silently change semantics.
• Teams that standardize on Git Bash across CI and local development want the agent's shell to match the shell the rest of the toolchain uses.

Today the runtime cannot express "use this specific shell" at all: the detection input (DetectShellInput) only accepts platform, env, and fileExists, and defaultShellPlan() is a cached, parameterless lookup.

Desired outcome

A user can explicitly configure Git Bash as the Bash tool shell on Windows and have that choice honored consistently across:

• The spawn path (shell-exec.ts / shell-run-manager.ts), using bash.exe -c ... (or -s from stdin for the legacy System32\bash.exe WSL shim) rather than PowerShell -Command.
• The PTY path (node-pty / ConPTY) so interactive and long-running commands behave like Bash.
• The prompt surfaces that declare the dialect to the model (bashToolShellGuidance, session-environment-prompt.ts), so the model writes Bash syntax and the tool description does not claim PowerShell.

Configuration should be a first-class, discoverable setting (e.g. a shell/shellPath option in the same place where the runtime already accepts an injected ShellPlan), with the existing auto-detection (pwsh > powershell > cmd) remaining the default when nothing is set. Validation should reject a path that is not a real Bash executable.

When nothing is configured, behavior must stay unchanged.

Alternatives or workarounds

• Today: there is no workaround. Detection is hard-coded and cached; a user cannot inject a shell path or force Bash without patching the source.
• Rejected — auto-include Git Bash in detection: we deliberately do not propose silently preferring Git Bash over PowerShell, because docs/windows-support.md establishes PowerShell-first as the Windows baseline and defaults should not change. This is purely an opt-in override.
• Considered — a generic "shell kind" selector (posix / pwsh / powershell / cmd / git-bash) surfaced in the runtime Host protocol and CLI, which would generalize the same mechanism for environments that want MSYS2 or WSL bash. This could be the umbrella under which the Git Bash option is delivered.

---

Technical context for reviewers

• Detection: packages/runtime/src/shell-detect.ts — detectShell(), defaultShellPlan(), buildShellSpawnPlan(), buildPtyShellSpawnPlan(), bashToolShellGuidance().
• Spawn consumers: packages/runtime/src/shell-exec.ts, packages/runtime/src/shell-run-manager.ts.
• Prompt/dialect declaration: packages/runtime/src/shell-tools.ts (withShellGuidance), packages/runtime/src/system-prompt/session-environment-prompt.ts.
• Injection point already exists: builtin-tools.ts accepts an injected shell?: ShellPlan; the gap is the user-facing configuration path to produce a Git Bash ShellPlan.

问题描述

在 Windows 上，Maka 的 Bash 工具总是解析为 PowerShell：detectShell()（位于 packages/runtime/src/shell-detect.ts）优先选择 PowerShell 7（pwsh），然后是 Windows PowerShell 5.1，最后才回退到 cmd.exe。代码里没有任何针对 Git Bash 的分支，用户也无法覆盖这个选择。

这对三类用户造成困扰：

• 已经在 Windows 上用 Bash/POSIX 写命令的用户（无论通过 Git Bash、MSYS2，还是 连接 WSL/远程环境），他们的肌肉记忆、shell 配置和别名都是 Bash 风格的。即使 环境里装了可用的 Bash，他们仍被迫把每条命令翻译成 PowerShell 语法。
• 模型从 Bash 中心的 prompt/SDK、或从文档命令为纯 POSIX 风格的项目里发出的 bash 风格命令，在 PowerShell 下会失败或语义悄悄改变。
• 在 CI 和本地开发中都统一使用 Git Bash 的团队，希望 agent 的 shell 与工具链 其余部分保持一致。

当前运行时完全无法表达"使用某个特定 shell"：检测输入（DetectShellInput） 只接受 platform、env、fileExists，而 defaultShellPlan() 是无参数的缓存 查找。

期望结果

用户可以显式把 Git Bash 配置为 Windows 上 Bash 工具的 shell，并且这一选择在 以下各处被一致地遵守：

• spawn 路径（shell-exec.ts / shell-run-manager.ts）：使用 bash.exe -c ...（对旧版 System32\bash.exe WSL 垫片则用 stdin 的 -s）， 而不是 PowerShell 的 -Command。
• PTY 路径（node-pty / ConPTY）：交互式和长命令能像 Bash 一样工作。
• 向模型声明方言的 prompt 表面（bashToolShellGuidance、 session-environment-prompt.ts）：模型会写 Bash 语法，工具描述也不会再声称 是 PowerShell。

配置应是一等公民、可被发现的设置（例如在运行时已支持注入 ShellPlan 的同一 位置增加 shell / shellPath 选项）；未设置时，现有的自动检测（pwsh > powershell > cmd）仍作为默认。校验应拒绝不是真实 Bash 可执行文件的路径。

未配置时，行为必须保持不变。

备选方案或变通做法

• 现状： 没有变通方案。检测是硬编码且缓存的；用户不修改源码就无法注入 shell 路径或强制使用 Bash。
• 已否决——把 Git Bash 自动纳入检测： 我们刻意不提议让 Git Bash 静默优先于 PowerShell，因为 docs/windows-support.md 已把 PowerShell-first 确立为 Windows 基线，默认行为不应改变。这只是可选的覆盖。
• 已考虑——通用的"shell 种类"选择器（posix / pwsh / powershell / cmd / git-bash），暴露在运行时 Host 协议和 CLI 中，这样能为想用 MSYS2 或 WSL bash 的环境泛化同一套机制。可作为承载 Git Bash 选项的更大框架。

---

给评审者的技术上下文

• 检测：packages/runtime/src/shell-detect.ts — detectShell()、 defaultShellPlan()、buildShellSpawnPlan()、buildPtyShellSpawnPlan()、 bashToolShellGuidance()。
• spawn 消费方：packages/runtime/src/shell-exec.ts、 packages/runtime/src/shell-run-manager.ts。
• prompt/方言声明：packages/runtime/src/shell-tools.ts （withShellGuidance）、packages/runtime/src/system-prompt/session-environment-prompt.ts。
• 注入点已存在：builtin-tools.ts 接受注入的 shell?: ShellPlan；缺口在于 生成 Git Bash ShellPlan 的用户可见配置路径。