MIT-licensed DSH tool plugin that replaces pwsh and WSL-only bash on Windows with Git for Windows' own bash.exe, registered as a `gitbash` tool with the same sandbox, timeout and background-job behaviour as the native shell tools.
DSH integration
Native runtime
Author-claimed
Safety audit
Unaudited
Last verified
2026-11-14
License
MIT
01What can it help you accomplish?
Let the model run shell commands on Windows without WSL and without waiting on PowerShell
A `gitbash` tool on par with the native `pwsh` and `bash` tools, backed by Git for Windows' own bash.exe — no WSL layer, and both `C:\...` and `/c/...` paths work
Windows DeepSeek Harness users whose machines have no WSL, or who find the native pwsh tool slow to start and laggy to run
Swap it in for pwsh without relearning the tool contract
The same call card, the same working-directory resolution, the same sandbox-escalation prompt (`sandbox_permissions` + `justification`) and the same `run_in_background` gating as the native tools
Teams that already have prompts and habits built around DSH's native shell tools
Keep shell execution inside the sandbox and inside a time budget
File-sandbox modes, a per-call timeout, output truncation and background jobs that return a jobId immediately
Operators who let an agent run shell commands on a real Windows workstation and need the same guard rails as the native tools
02How to install into DeepSeek Harness
Prerequisites
- Git for Windows installed (from https://git-scm.com/download/win) so that a bash.exe exists — the tool auto-detects `C:\Program Files\Git\bin\bash.exe`, `C:\Program Files\Git\usr\bin\bash.exe`, a scoop install located via `SCOOP`, or any `bash.exe` on PATH
- A DSH profile you can add a bundle to; the plugin is not on npm, so `dsh plugin add dsh-tool-gitbash` fails and the GitHub form is the only remote path
Installation steps
- 01
Install straight from GitHub with a pinned commit: `dsh plugin --profile <your-profile> add github:buhuikongpan/dsh-win-gitbash#<commit-sha>` — the install command handles the `@deepseek-ai/*` peer dependencies itself
$ dsh plugin --profile <your-profile> add github:buhuikongpan/dsh-win-gitbash#<commit-sha>
- 02
Enable the bundle in the DSH composition / profile by adding `dsh-tool-gitbash` to `dsh.profile.bundles`
- 03
If pnpm blocks the git-hosted plugin's `prepare` build, add the key pnpm prints to that profile's `pnpm-workspace.yaml` (`allowBuilds`) and retry
- 04
Alternative manual route: put the package into DSH's `node_modules` (e.g. `%APPDATA%\npm\node_modules\dsh-tool-gitbash`) or `link:` it, make the `@deepseek-ai/*` peers available, then enable the plugin in the composition
Verify the integration
- After the restart the model has the `gitbash` tool. If it does not, check stderr for `skipping profile bundle "dsh-tool-gitbash"` — that means a `@deepseek-ai/dsh-*` peer range does not cover the running version
03DSH integration and capability boundaries
DSH tool plugin declaring a `dsh.bundle` manifest: it registers a `gitbash` tool next to the native `pwsh` and `bash` tools and calls Git for Windows' own bash through `ctx.subprocess`
gitbash tool call
`command` (run through `bash -c`), an optional one-line `description`, `workdir` (session directory by default), `timeoutMs` (120s by default, 600s maximum) and, when the config exposes it, `run_in_background`→the command's output, truncated if needed; background calls return a jobId immediately
runs arbitrary shell commands as the user on the Windows machine`run_in_background` only appears when `enableRunInBackground` is onbash.exe auto-detection with manual override
nothing, or a `bashPath` value in the plugin row of `cordis.patch.yml`→the resolved Git Bash executable; the tool skips the WSL launcher in `System32` and falls back to a configured path when detection fails
the plugin row in `cordis.patch.yml` is the place the override livesSandbox escalation identical to the native tools
a call that the active sandbox policy confines, plus `sandbox_permissions` and `justification`→an approval prompt through `approveEscalation` + `ctx.approval`, with the sandbox policy re-read on every call
the policy is resolved at call time, not at `apply()` time, so `read-only` / `workspace-write` boundaries stay effective
04Who is it for? When not to use it?
Good for
- Windows DeepSeek Harness users whose machines have no WSL, or who find the native pwsh tool slow to start and laggy to run
- Teams that already have prompts and habits built around DSH's native shell tools
- Operators who let an agent run shell commands on a real Windows workstation and need the same guard rails as the native tools
Not for
- Windows only, and it depends on Git for Windows being installed: the whole point is to use Git Bash instead of pwsh or a WSL-only bash. The README offers no macOS or Linux path.
- Declares `engines.dsh: ">=0.1.0-rc.6 <0.3.0"` with matching peer ranges, so DSH 0.1.x and 0.2.x load it. DSH validates every profile bundle's peers at startup: one mismatched `@deepseek-ai/dsh-*` range makes it skip the bundle entirely, `cordis.patch.yml` stops applying and the model simply has no `gitbash` tool.
- The package is not published to npm (`dsh-tool-gitbash` is 404 on npmjs and npmmirror), so the plain `dsh plugin add` fails; installs go through the `github:` form with a pinned commit, and pnpm may block the git-hosted `prepare` build until you add its `allowBuilds` key.
- The tool executes shell commands as your user; confinement comes from DSH's sandbox policy, which the plugin re-reads on every call and only falls back from when the composition has no policy service at all. Escalating out of a confined call requires both `sandbox_permissions` and `justification`.
05Compatibility, maintenance and safety notes
- Windows only, and it depends on Git for Windows being installed: the whole point is to use Git Bash instead of pwsh or a WSL-only bash. The README offers no macOS or Linux path.
- Declares `engines.dsh: ">=0.1.0-rc.6 <0.3.0"` with matching peer ranges, so DSH 0.1.x and 0.2.x load it. DSH validates every profile bundle's peers at startup: one mismatched `@deepseek-ai/dsh-*` range makes it skip the bundle entirely, `cordis.patch.yml` stops applying and the model simply has no `gitbash` tool.
- The package is not published to npm (`dsh-tool-gitbash` is 404 on npmjs and npmmirror), so the plain `dsh plugin add` fails; installs go through the `github:` form with a pinned commit, and pnpm may block the git-hosted `prepare` build until you add its `allowBuilds` key.
- The tool executes shell commands as your user; confinement comes from DSH's sandbox policy, which the plugin re-reads on every call and only falls back from when the composition has no policy service at all. Escalating out of a confined call requires both `sandbox_permissions` and `justification`.
MIT · README evidence only, latest release v0.2.3, not published to npm, no security audit
06Frequently asked questions
How do I install it into DeepSeek Harness?
The package is not on npm, so use the GitHub form with a pinned commit: `dsh plugin --profile <your-profile> add github:buhuikongpan/dsh-win-gitbash#<commit-sha>`. Then add `dsh-tool-gitbash` to `dsh.profile.bundles` in the profile and restart — the model gets the `gitbash` tool.
What has to be installed on the machine first?
Only Git for Windows, which supplies bash.exe. The tool auto-detects `C:\Program Files\Git\bin\bash.exe`, `C:\Program Files\Git\usr\bin\bash.exe`, a scoop install found through `SCOOP`, or any `bash.exe` on PATH; it skips the WSL launcher in `System32`. If detection fails, set `bashPath` in the plugin row of `cordis.patch.yml`.
The plugin installed but the model has no gitbash tool — why?
Most likely a peer-version mismatch. DSH checks every profile bundle's `@deepseek-ai/dsh-*` peers at startup and skips the whole bundle if one range does not cover the running version, printing `skipping profile bundle "dsh-tool-gitbash"` to stderr. The declared range is `>=0.1.0-rc.6 <0.3.0`, so confirm it covers the DSH you are on after a major upgrade.
Does it behave like the native pwsh and bash tools?
Yes by design: it reuses DSH's built-in terminal card, resolves the working directory the same way (sandbox root first, otherwise the session cwd via `canonicalPath`), and triggers the same sandbox-escalation prompt through `sandbox_permissions` + `justification`. `run_in_background` is only exposed when `enableRunInBackground` is on, and `timeoutMs` defaults to 120s with a 600s ceiling.
Is the sandbox still enforced?
The plugin resolves the sandbox policy at call time rather than at `apply()`, because cordis loads plugin rows in parallel and this row can come up before `sandbox-policy`. It only falls back to an unsandboxed tool when the composition genuinely has no policy service.
07Related DSH workflows
dsh-our-free-model
by ebony-vinyl
Adds model choices, availability checks, usage panels, and a local OpenAI-compatible forwarder.
dsh-routing-suite
by yjh051108
dsh-routing-suite — injector + router-standard kit: install the runtime injector first, then the task-aware reasoning-mode router preset (measured P1-P23).
dsh-ops
by t-auto
Run Bash and PowerShell commands, search and edit local files, and manage long-running background jobs from DSH.
brooks-lint
by hyhmrright
Portable AI code quality reviews for Codex, Cursor, Copilot and other coding agents: six Agent Skills for architecture, technical debt, tests and remediation.
08Data and sources
**面向 Windows 的 Git Bash 工具插件**（DSH / DeepSeek Harness tool plugin）
以 DSH 工具插件形式注册为 `gitbash`
本工具作为 `ctx.subprocess` 消费者直接调用 Git for Windows 自带 bash，
This page is generated from the project’s public documentation, repository metadata and a structured parse of DSH Plugins; last verified on 2026-11-14. Found an error? Submit a correction.
Best DeepSeek Harness Plugins
Twelve plugins worth installing first — picked from the whole catalog, across every category.