MIT 开源的 DSH 工具插件，用 Git for Windows 自带的 bash.exe 替代 Windows 上的 pwsh 与只能在 WSL 里跑的 bash，注册为 `gitbash` 工具，沙箱、超时与后台任务行为与原生 shell 工具一致。
DSH 适配
原生运行时
作者声明
安全审计
未审计
最后核验
2026-11-14
许可证
MIT
01它能帮你完成什么？
在 Windows 上让模型执行 shell 命令，既不用 WSL，也不用等 PowerShell 慢慢启动
一个与原生 `pwsh`、`bash` 平级的 `gitbash` 工具，背后是 Git for Windows 自带的 bash.exe——没有 WSL 层开销，`C:\...` 与 `/c/...` 两种路径都能用
机器上没装 WSL、或者嫌原生 pwsh 工具启动慢、执行卡顿的 Windows DeepSeek Harness 用户
把 pwsh 换掉，但不用重新适应一套工具契约
与原生工具一致的调用卡片、一致的工作目录解析、一致的沙箱升级提问（`sandbox_permissions` + `justification`），`run_in_background` 的暴露条件也一样
提示词和习惯已经围绕 DSH 原生 shell 工具搭好的团队
让 shell 执行留在沙箱里、也留在时间预算里
文件沙箱模式、单次调用超时、输出截断，以及立即返回 jobId 的后台任务
允许 agent 在真实 Windows 工作站上跑 shell 命令、需要和原生工具同级护栏的运维与开发者
02如何接入 DeepSeek Harness？
前置条件
- 先装好 Git for Windows（下载地址 https://git-scm.com/download/win），确保存在一个 bash.exe——工具会自动探测 `C:\Program Files\Git\bin\bash.exe`、`C:\Program Files\Git\usr\bin\bash.exe`、通过 `SCOOP` 定位的 scoop 安装，以及 PATH 上的任意 `bash.exe`
- 一个可以添加 bundle 的 DSH profile；插件尚未发布到 npm，`dsh plugin add dsh-tool-gitbash` 会失败，`github:` 形式是目前唯一可用的远程方式
安装步骤
- 01
从 GitHub 安装并 pin 一个 commit：`dsh plugin --profile <你的profile> add github:buhuikongpan/dsh-win-gitbash#<commit-sha>`——安装命令会自行处理 `@deepseek-ai/*` peer 依赖
$ dsh plugin --profile <你的profile> add github:buhuikongpan/dsh-win-gitbash#<commit-sha>
- 02
在 DSH 组合（composition）/ profile 中启用该 bundle：把 `dsh-tool-gitbash` 加进 `dsh.profile.bundles`
- 03
如果 pnpm 拦下了 git 托管插件的 `prepare` 构建，按提示把它打印的 key 加进该 profile 的 `pnpm-workspace.yaml`（`allowBuilds`）后重试
- 04
另一种手动方式：把包放进 DSH 的 `node_modules`（例如 `%APPDATA%\npm\node_modules\dsh-tool-gitbash`）或用 `link:` 指向仓库，备齐 `@deepseek-ai/*` peer，再在组合中启用插件
验证接入成功
- 重启后模型就有 `gitbash` 工具了。如果没有，先看 stderr 里有没有 `skipping profile bundle "dsh-tool-gitbash"`——那说明某个 `@deepseek-ai/dsh-*` peer 区间没覆盖当前运行时版本
03DSH 适配与能力边界
声明了 `dsh.bundle` manifest 的 DSH 工具插件：与原生 `pwsh`、`bash` 平级注册一个 `gitbash` 工具，作为 `ctx.subprocess` 消费者直接调用 Git for Windows 自带的 bash
gitbash 工具调用
`command`（经 `bash -c` 执行）、可选的一句话 `description`、`workdir`（默认会话目录）、`timeoutMs`（默认 120s、上限 600s），以及配置开启时的 `run_in_background`→命令输出，过长会被截断；后台调用立即返回 jobId
以你的用户身份在 Windows 机器上执行任意 shell 命令`run_in_background` 只在 `enableRunInBackground` 开启时才出现在工具 schema 里bash.exe 自动探测与手动覆盖
什么都不配，或在 `cordis.patch.yml` 的插件行里给一个 `bashPath`→解析出的 Git Bash 可执行文件；探测时会跳过 `System32` 下的 WSL 启动器，探测失败则用配置的路径
覆盖路径写在 `cordis.patch.yml` 的插件行里与原生工具一致的沙箱升级
被当前沙箱策略限制的调用，加上 `sandbox_permissions` 与 `justification`→经由 `approveEscalation` + `ctx.approval` 的权限提问，且每次调用都重新解析沙箱策略
策略在调用时刻解析、而不是在 `apply()` 期定死，`read-only` / `workspace-write` 边界才不会失效
04适合谁？何时不该用？
适合
- 机器上没装 WSL、或者嫌原生 pwsh 工具启动慢、执行卡顿的 Windows DeepSeek Harness 用户
- 提示词和习惯已经围绕 DSH 原生 shell 工具搭好的团队
- 允许 agent 在真实 Windows 工作站上跑 shell 命令、需要和原生工具同级护栏的运维与开发者
不适合
- 只面向 Windows，而且依赖 Git for Windows：它的全部意义就是用 Git Bash 替代 pwsh 或只能在 WSL 里跑的 bash。README 没有给出 macOS 或 Linux 的用法。
- 声明 `engines.dsh: ">=0.1.0-rc.6 <0.3.0"`，peer 区间同区间，所以 DSH 0.1.x 与 0.2.x 都能加载。但 DSH 启动时会逐个校验 profile bundle 的 peer：只要一个 `@deepseek-ai/dsh-*` 区间不匹配，整个 bundle 会被跳过，`cordis.patch.yml` 不生效，模型就没有 `gitbash` 工具。
- 包没有发布到 npm（`dsh-tool-gitbash` 在 npmjs 与 npmmirror 上都是 404），所以直接的 `dsh plugin add` 会失败；安装只能走带 commit pin 的 `github:` 形式，而且 pnpm 可能拦下 git 托管插件的 `prepare` 构建，要先补 `allowBuilds`。
- 工具以你的用户身份执行 shell 命令；约束来自 DSH 的沙箱策略，插件每次调用都重新读取，只有在组合里确实没有 policy 服务时才回退成无沙箱。要从受限调用里升级，必须同时给 `sandbox_permissions` 和 `justification`。
05兼容性、维护与安全提示
- 只面向 Windows，而且依赖 Git for Windows：它的全部意义就是用 Git Bash 替代 pwsh 或只能在 WSL 里跑的 bash。README 没有给出 macOS 或 Linux 的用法。
- 声明 `engines.dsh: ">=0.1.0-rc.6 <0.3.0"`，peer 区间同区间，所以 DSH 0.1.x 与 0.2.x 都能加载。但 DSH 启动时会逐个校验 profile bundle 的 peer：只要一个 `@deepseek-ai/dsh-*` 区间不匹配，整个 bundle 会被跳过，`cordis.patch.yml` 不生效，模型就没有 `gitbash` 工具。
- 包没有发布到 npm（`dsh-tool-gitbash` 在 npmjs 与 npmmirror 上都是 404），所以直接的 `dsh plugin add` 会失败；安装只能走带 commit pin 的 `github:` 形式，而且 pnpm 可能拦下 git 托管插件的 `prepare` 构建，要先补 `allowBuilds`。
- 工具以你的用户身份执行 shell 命令；约束来自 DSH 的沙箱策略，插件每次调用都重新读取，只有在组合里确实没有 policy 服务时才回退成无沙箱。要从受限调用里升级，必须同时给 `sandbox_permissions` 和 `justification`。
MIT · 仅有 README 证据，最新版本 v0.2.3，未发布到 npm，未做安全审计
06常见问题
怎么把它装进 DeepSeek Harness？
包没发布到 npm，所以用带 commit pin 的 GitHub 形式：`dsh plugin --profile <你的profile> add github:buhuikongpan/dsh-win-gitbash#<commit-sha>`。然后把 `dsh-tool-gitbash` 加进该 profile 的 `dsh.profile.bundles` 并重启，模型就会拿到 `gitbash` 工具。
机器上要先装什么？
只需要 Git for Windows，它提供 bash.exe。工具会自动探测 `C:\Program Files\Git\bin\bash.exe`、`C:\Program Files\Git\usr\bin\bash.exe`、通过 `SCOOP` 定位的 scoop 安装，以及 PATH 上的任意 `bash.exe`，并跳过 `System32` 下的 WSL 启动器。探测失败时，在 `cordis.patch.yml` 的插件行里设 `bashPath`。
插件装上了，模型却没有 gitbash 工具，为什么？
多半是 peer 版本不匹配。DSH 启动时会校验每个 profile bundle 的 `@deepseek-ai/dsh-*` peer，只要有一个区间不覆盖当前版本，整个 bundle 就被跳过，并在 stderr 打印 `skipping profile bundle "dsh-tool-gitbash"`。插件声明的区间是 `>=0.1.0-rc.6 <0.3.0`，大版本升级后先确认它覆盖你正在用的 DSH。
它的行为和原生 pwsh / bash 工具一样吗？
按设计是一样的：复用 DSH 内置终端卡片，工作目录解析规则相同（沙箱根优先，否则会话 cwd 经 `canonicalPath` 规范化），沙箱升级提问同样由 `sandbox_permissions` + `justification` 触发。`run_in_background` 只在 `enableRunInBackground` 开启时暴露，`timeoutMs` 默认 120s、上限 600s。
沙箱还生效吗？
生效。插件在调用时刻解析沙箱策略而不是在 `apply()` 期定死，因为 cordis 并行装载各 plugin row，本插件的 row 可能早于 `sandbox-policy` 注册。只有组合里确实没有 policy 服务时，才回退为无沙箱工具。
07相关的 DSH 工作流
dsh-our-free-model
作者 ebony-vinyl
在 dsh 里装上这个插件即可，无需登录、注册或填 API Key，就能使用包括 DeepSeek V4.1 Flash、Kimi K3 在内的前沿模型——完全免费，不限量。 All you do is install this plugin in dsh: no login, no sign-up, no API key — the frontier models are just there, DeepSeek V4.1 Flash and Kimi K3 among them. Completely free, with no usage cap.
dsh-routing-suite
作者 yjh051108
DeepSeek Harness（dsh）路由套件：先装运行时注入器，再加载任务感知的推理模式路由预设（已实测 P1-P23）。
dsh-ops
作者 t-auto
A toolkit for low-level operations in DSH, designed to reduce token usage and task execution time / DSH 底层操作工具插件，旨在减少 Token 消耗与任务耗时
brooks-lint
作者 hyhmrright
基于 12 本经典工程书籍的 AI 代码评审工具，提供腐化风险诊断、书籍引用、严重度标签及 6 种分析模式。
08数据与来源
**面向 Windows 的 Git Bash 工具插件**（DSH / DeepSeek Harness tool plugin）
以 DSH 工具插件形式注册为 `gitbash`
本工具作为 `ctx.subprocess` 消费者直接调用 Git for Windows 自带 bash，
页面基于项目公开文档、仓库元数据和 DSH Plugins 的结构化解析生成；最后核验于 2026-11-14。发现错误？提交更正。
最佳 DeepSeek Harness 插件
从全目录挑出的 12 个值得优先安装的插件，覆盖各个分类。