Jesse-njx/dsh-docker
bundle
dsh-docker — typed, guarded container control for DSH: structured docker/compose tools, project-aware targeting, an approval gate for destructive ops, service-health context, and a replayable status-table renderer
Install
npx @deepseek-ai/dsh plugin --profile web add @dsh-docker/bundleRestart `dsh web` after install. Bundle APIs can change during the developer preview.
README badge
[](https://dshhub.dev/plugins/jesse-njx-dsh-docker)Paste this into your README. The star count updates with every catalog sync.
From the README
Excerpt from Jesse-njx/dsh-docker, cleaned of badges and images.
dsh-docker
Typed, guarded container control for DSH — structured Docker access that is hard to destroy by accident.
dsh-docker is a plugin bundle for DeepSeek Harness. It wraps the docker CLI through DSH's ctx.shell seam and gives your agent a typed, project-aware, guarded surface for containers and compose stacks — every tool returns structured JSON (await tools.docker_ps(...) gets real objects, never scraped prose), destructive operations require human sign-off through the approval gate, and stop dev-api means your local compose service, not a coincidentally-named container on the machine.
┌──────────────┐ docker ps --format json ┌──────────────┐
│ agent tool │ ───────────────────────────▶ │ ctx.shell │ ──▶ docker CLI
│ call │ │ (sandbox/ │
└──────┬───────┘ │ remote) │
│ classify() └──────────────┘
▼
┌──────────────┐ destructive? ┌──────────────────────┐
│ pre-execute │ ──────────────▶ │ approval gate │ allowed-once → run
│ policy │ (guarded) │ (ctx.approval, │ rejected/unavailable
└──────┬───────┘ │ fails closed) │ → refused
│ safe / token recorded └──────────────────────┘
▼
┌──────────────┐ hard-destructive without a token? → refused (monotonic)
│ ctx.tools │
│ .guard() │ backstop: no later listener can undo a denial
└──────────────┘
Flagship demo — debug a failing integration test
Your agent runs a failing test against docker-compose.yml:
$ docker_ps → { containers: [{ name: "app-api-1", state: "running", ... }] }
$ docker_logs { container: "app-api-1", tail: 200 }
→ { lines: [...], truncated: true } # capped pull never reads as complete
$ docker_compose_ps → { project: "app", services: [{ name: "db", state: "running" }] }
The agent reads freely. The moment it tries something destructive — docker_rm -f on the running API container, docker_rmi on an image a container still uses, docker system prune -a, or docker compose down -v — the call is paused and routed to the human approval gate:
⏸ docker_rmi "app-api:latest" — image in use by container app-api-1
[approve] [reject]
No approval channel, or a denied request? The operation is refused. execReadOnly is on by default, so docker_exec without write/interactive never prompts, and a writeful exec is treated as destructive. And even if some other plugin's policy said "allow", the monotonic guard still refuses the hard-destructive set unless this call carries the dsh-docker approval token.
Install
# From the npm registry once published, or straight from this repository:
dsh plugin --profile web add @dsh-docker/bundle # npm (when published)
dsh plugin --profile web add github:Jesse-njx/dsh-docker # or: straight from GitHub
Install into whatever profile your agents run under (web for the desktop UI, headless for CLI sessions). The bundle mounts the tools, the policy, the opt-in health context, and the web status renderer.
Tools
Every tool is a defineTool with typed parameters and a structured output schema — Code Mode sees await tools.<name>(...) returning the canonical JSON value, never rendered prose.
Containers
…

