【Bug】Windows 上官方 minimal（极简模式）预设的 bash 无法启动：默认 shellPath /bin/bash 不可解析（实测+修复建议）

[taonokenshin]

环境

• 系统：Windows 11 Pro 25H2（build 10.0.26200）
• DSH：0.1.0-rc.6（npm 全局安装）
• Git for Windows 2.55 已安装（C:\Program Files\Git，bash 不在 PATH）
• node v24.19.0

现象

官方 minimal 预设（极简模式）是默认预设之一，但该预设唯一的命令工具"持久 bash"在 Windows 上完全无法启动（会话中执行任何命令都失败）；该预设也没有 web 搜索工具。用户在极简模式下既不能执行命令，也不能联网——这是"预设级别"的功能缺失，不是用户环境问题。

根因定位

1. config/agent-presets/minimal/agent.cordis.yml 中 terminal-bash（@deepseek-ai/dsh-terminal-bash）未配置 shellPath，插件默认值是 /bin/bash（shellPath: z.string().default("/bin/bash")）。
2. dsh-subprocess-local 的 spawnTerminal 把 argv[0] 原样交给 node-pty；Windows 的 CreateProcess 对含 / 的路径不做 PATH 搜索。所以即使装了 Git Bash、即使把 Git\bin 加入 PATH，/bin/bash 也永远无法解析。
3. 对比：standard 预设已经做了平台适配（win32 禁用 tool-bash、启用 tool-pwsh），minimal 却没有——同一发行版内行为不一致，说明这是遗漏而非设计。

实测证据（node-pty 直测）

• pty.spawn('/bin/bash', ['--noprofile','--norc','-i'], …) → 抛错 File not found（把 Git\bin 加入 PATH 后依旧失败）
• pty.spawn('C:/Program Files/Git/bin/bash.exe', …) → 正常，echo PTY_OK_$((6*7)) 输出 PTY_OK_42

建议修复（任选其一）

1. minimal 预设的 terminal-bash 增加平台分支（如 shellPath: !!js process.platform === 'win32' ? '<Git Bash 绝对路径>' : '/bin/bash'），并在 win32 下自动探测 Git Bash 常见安装路径（C:\Program Files\Git\bin\bash.exe、%LOCALAPPDATA%\Programs\Git\bin\bash.exe 等）或 PATH 中的 bash.exe；
2. 或在 terminal-bash 后端 spawn 前做一次可执行文件解析（参考 resolveExecutable 的思路，加入 Windows 特殊路径探测），让 /bin/bash 能回退到 Git Bash；
3. 至少官方文档注明：minimal 预设的 bash 在 Windows 需要 Git Bash/WSL 且需显式配置 shellPath。

用户侧已有解法（供其他用户参考）

• 社区插件 dsh-win32（dsh-win32 — 极简模式终于能在 Windows 上跑了（持久 Git Bash）| Real Minimal mode on Windows #1832）已提供持久 Git Bash；
• 或把 minimal 复制为用户预设，显式设置 terminal-bash.shellPath 指向 Git Bash（本人按此方案解决，并顺带补了 web 搜索与 read/grep/glob 工具）。

附带问题（与 #1841 可能相关）

工具调用挂起后（本案例为第三方插件的目录扫描长时间无返回），UI 的暂停/关闭均无效、回合永不结束，后续消息被排队到 next-step 后永远不被消费；且没有任何 CLI 强制中断手段，只能重启整个 dsh web 进程。希望提供"强制中断当前运行"的兜底能力（UI 或 CLI 均可）。

结论

这不是个别电脑的兼容问题：同一发行版里 standard 有 Windows 适配而 minimal 没有，属于官方预设对 Windows 的适配缺失，建议在后续版本中修复。

[zoahdev]

Independently reproduced the core claim and staged a patch.

Repro (our Windows box, Node 24, node-pty 1.1.0)

pty.spawn('/bin/bash', ['--noprofile','--norc','-c','echo PTY_TEST_42'])
? throws: File not found

(Git Bash is not installed on this box, so the C:/Program Files/Git/bin/bash.exe positive case is not re-verified here ? your evidence covers that half.)

Staged patch ? https://github.com/zoahdev/deepseek-harness/tree/fix/terminal-bash-win32-shell

packages/terminal/terminal-bash/src/index.ts:

• win32 + default shellPath (/bin/bash) ? probe PATH bash.exe/bash, Git for Windows locations (Program Files\Git�in�ash.exe, %LOCALAPPDATA%\Programs\Git�in�ash.exe)
• still missing ? actionable error naming the fix (install Git/WSL or set shellPath) instead of node-pty's bare File not found
• non-Windows and explicitly-configured paths are untouched

Cherry-pick-ready when the PR channel opens.

On the force-interrupt gap in the same report: that matches the #1841 family (unpaired tool_call leaves the loop un-windable). A CLI-level "abort current turn" is genuinely missing; happy to spec it as a companion RFC if useful.

[zoahdev]

Toolized: dsh-plugin-doctor v1.8.0 adds a win-bash check to --env ? it verifies the default /bin/bash (minimal preset) can resolve on Windows by probing PATH, Git for Windows locations, and WSL (System32\bash.exe). Missing bash ? actionable FAIL naming discussion #1856.

Verified on this box (Windows, no Git Bash installed):

win-bash PASS | bash resolved: C:\WINDOWS\system32�ash.exe   # WSL launcher

Tests 19/19. Release: https://github.com/zoahdev/dsh-plugin-doctor/releases/tag/v1.8.0 ? the check also works as a pre-boot tripwire for the preset gap, independent of the staged upstream patch.

[sjh9714]

这个 bug 的另一半在 #1889。shellPath 可解析之后，PTY 还会在 createProcessInspector 处抛 win32 不支持。参考实现（CIM + taskkill，MIT，含单测和 windows-latest CI 实测）已附在那边，与楼里的 staged 修复正好互补。