Skip to content

DeepSeek Harness Ecosystem as of 5 Sep 2026: Plugins, Vanilla Fit, and Permission Modes

Research date: 2026-09-05. Question: how mature is the ecosystem now, is the vanilla install enough for most use cases, has the community converged on must-have plugins, and does DSH have a permission mode like Codex's auto-approve / agent-reviewed tool calling? Inline URLs are the primary evidence; community snapshots are labeled as such. The implementation-level cross-harness comparison lives in the companion page Coding-agent auto-approve modes (Sep 2026).

TL;DR

  • Core is still a developer preview, just past its first RC of 0.1.2. @deepseek-ai/dsh is at 0.1.2-rc.1 (published around 2 Sep 2026; npm, release notes), roughly three weeks after the 13 Aug launch. The release still carries the official safety notice: no security audit has been done and sandbox/approval/permission controls do not guarantee isolation (release notes).
  • Plugins are numerous but not "mature" in the marketplace sense. The dsh-plugin topic sits around 13.5k–14.6k repositories (dsh.works, dsharness.org), inflated by template spam and topic-riders. Curated quality directories keep only about 2k entries (Oh-My-DSH).
  • Vanilla is sufficient for the mainstream coding baseline. The shipped web/Standard profile exposes shell, file editing, glob/grep, web fetch/search, planning, skills, subagents, sessions, background jobs, and user questions out of the box (quickstart, tool catalog).
  • "Must-haves" have converged as categories, not yet as stable winners: plugin market/management, Web-UI workbench upgrades, vision for text-only routes, cross-session memory, browser control, and security/health audit tooling.
  • Permission modes (follow-up): vanilla DSH still ships only workspace-write + ask and danger-full-access + never — no built-in Codex-style "approve-for-me" / agent reviewer yet (permission presets, approval subsystem). The community has ported the pattern through auto-review/auto-approval plugins; the architecture has converged but no plugin is a stable winner.

1. Core project status

Channel Version (5 Sep 2026) Source
npm @deepseek-ai/dsh 0.1.2-rc.1 npm
PyPI deepseek-harness-sdk 0.1.2rc1 wheel PyPI
GitHub release v0.1.2-rc.1, pre-release release
Launch baseline v0.1.0-rc.6, 13 Aug 2026 launch coverage

The path to 0.1.2-rc.1 was churny even for a preview: 0.1.0-rc.7 → rc.8 (19 Aug) → 0.1.1-rc.2 (21 Aug) → 0.1.2-alpha.1 (27 Aug) → alpha.2…alpha.5 (through 2 Sep) → 0.1.2-rc.1 (2–3 Sep) (community timeline, Aliyun tutorial). Release notes list pre-GA behavior: legacy APIProxy removed, "Code Mode" renamed "PTC mode", optional SQLite session backend removed, and Session.events replaced by on-demand read APIs (release notes).

The repo has adopted an "everything is a plugin / profile" architecture: dsh --profile <name> boots named compositions such as web, headless, sdk, and acp (npm README).

2. Plugin ecosystem: size vs. signal

Metric Value As of Source
Repos tagged dsh-plugin on GitHub topic ~13.6k 4 Sep 2026 dsh.works
Repos indexed by dsharness directory 14,566 1 Sep 2026 dsharness.org
dsharness "verified plugins" (loads via Cordis or ships a cordis.yml) 8,083 1 Sep 2026 dsharness.org
Rejected by dsh.works registry scan (no install path, spam, etc.) ~2.4k of 15k opened 4 Sep 2026 dsh.works
Curated entries in Oh-My-DSH 2,119 5 Sep 2026 Oh-My-DSH
Launch-day topic size 431 repos 13 Aug 2026 dsh.works

The two honest numbers to remember: 14k–15k repos is the raw topic, and only thousands (or ~2k for curated quality) are real installable plugins.

Known ecosystem problems:

  • Topic spam is structural — ~16% of dsh.works' scanned universe was rejected, mostly repos with the tag but no dsh manifest/dependency/SKILL.md (dsh.works).
  • npm metadata was unreliable — 298 of 582 registry claims pointed at npm packages that did not exist, with ownership mismatches (dsh.works).
  • Compatibility lags releases — community reviews found many high-star plugins failing to install/boot on recent DSH releases (dshpkg, Atlas Cloud roundup).
  • The plugin API itself keeps moving — the earlier .dsh-plugin manifest format was removed with no migration path, and registries now require version+date verification evidence (dsh.works).
  • Community governance is ad hoc — multiple "markets" use incompatible metadata; there is no unified pre-publish check, fault diagnosis, or abandonment policy (woshipm).

By the standards of a settled plugin ecosystem (stable ABI, package registry/curation, security review), no, this is not mature yet. By the standards of a three-week-old plugin-first project, it is unusually active: integrity-checked directories (DSH Plugin Hub), spam-filtered registries (dsh.works), and health/security CLIs (dshpkg).

3. Is vanilla enough for most use cases?

The official quickstart is four steps: npx @deepseek-ai/dsh web, add a model key, pick a workspace, run a task (quickstart). The shipped tool catalog includes persistent bash, file read/write/edit with read-before-write, glob/grep, web search/fetch (default on with SSRF protection in 0.1.2-rc.1), planning, skills, subagents, goals/todos, workflow, MCP servers, custom providers, and background jobs (tool catalog, release notes). A community deep-dive reached the same conclusion: basic project development does not require plugins; lightweight instructions belong in skills, not plugins (analysis).

What vanilla does not give you:

  1. A richer Web workbench — file tree + editor + terminal + Git side-by-side (dsh-web-ui, DSH-better-sidebar).
  2. Vision for text-only model routes — the chat-completions route is documented text-only; modlens bridges images via OCR/layout evidence (provider guide, modlens).
  3. Cross-session persistent memory — community memory plugins such as dsh-mnemon compete without a stable first-party layer.
  4. Browser control — several dsh-browser implementations compete.
  5. Plugin discovery/management UX — dsh-market is commonly installed first (dsh-market).
  6. TUI/desktop shells and ecosystem health tooling — terminal UIs, desktop wrappers, and security scanners (dshpkg).

So: vanilla is enough for chat + read/edit files + run commands + web search + subagents; it is not enough for an IDE-like shell, images on text-only models, durable cross-session memory, or browser control.

4. Has the community converged on "must-have" plugins?

Category-level convergence: yes. Independent lists keep pointing at the same capability slots:

Category Community front-runners (early Sep 2026) Evidence
In-app plugin market dsh-market (npm dshmarket), dsh-find-plugin dsh-market, Composio
Web-UI workbench dsh-web-ui, DSH-better-sidebar, dsh-at-file dsh.works
Vision for text-only routes modlens (v3.x on npm) modlens
Cross-session memory dsh-mnemon and rivals; no winner dsh.works
Browser control several dsh-browser projects GitHub topic
Plugin security & health dshpkg, dsh-poison-guard, dsh-plugin-doctor dshpkg
Cost/billing visibility dsh-cost-meter, dsh-usage-stats and variants Atlas Cloud

Specific-name convergence: no. Projects reuse names (dsh-browser, dsh-memory, several "awesome" lists with conflicting counts/owners), the official harness keeps absorbing formerly plugin-level features, and compatibility breaks every release (dsh.works, release notes).

5. Follow-up: is there a permission mode like Codex's auto-approve / auto-review?

Not in vanilla DSH yet, but yes as a community plugin pattern.

Vanilla DSH's permission layer is two knobs:

  • Sandbox modes: read-only, workspace-write, danger-full-access.
  • Approval policies: ask (delegate to composed answerers; no answerer → fail-closed unavailable) and never (deterministically reject every ask).
  • Decision vocabulary: the only grant is one-shot allowed-once; there is no allow-always or remembered grant.

The shipped permission-preset table exposes only workspace-write (+ ask) and danger-full-access (+ never) (permission presets, approval subsystem). What vanilla does provide is the seam for the feature: approval/request is a waterfall, plugins can register answerers, and the official ACP bridge already provides one-shot machine decisions for its own agents (approval subsystem).

Since late August, several independent plugins added a "middle" permission preset that mirrors Codex auto-review. Representative verified projects:

  • Letter2025/dsh-approval-llm — model-approval ("Approve for me"): deterministic allow/deny/human-only routing, then a separate reviewer model returning ALLOW / DENY / ESCALATE; fail-to-human; circuit breaker.
  • Xinlong-Wu/dsh-auto-review — auto-review preset; provable read-only ops pass; Guardian model reviews shell/network/MCP/escalations; one-shot grants only.
  • log-li/dsh-automode — auto-mode: deterministic deny/allow rules + allowPaths, then a cost-aware two-stage classifier; fail-closed; circuit breaker → human.
  • gbthui/dsh-auto-review — reviewer answers approval/request first; per-turn breaker; /approve N single exact retry.
  • aa2246740/dsh-auto-review — Approve for me tier preserving workspace-write + ask.
  • StyxNether/dsh-auto-approval-plugin — deterministic rule engine, no LLM: auto-approves harmless commands and trusted-area targets; everything else asks.
  • Scotlight/dsh-guardian-approval — fixed reviewer model with the Codex Guardian risk × authorization policy; three-state breaker; fails closed to human.

The shared architecture across implementations: keep workspace-write, decide deterministic cases first, let a separate reviewer (clean context, real tool args, isolated from the main agent) decide boundary-crossing asks one-shot, fail closed on reviewer failure, add a circuit breaker, and keep a human answerer as final fallback. The implementation depth and cross-harness context are covered in the companion page Coding-agent auto-approve modes (Sep 2026).

6. Practical recommendation

  1. Start vanilla for ordinary coding work. Re-evaluate only when you hit a concrete gap.
  2. If adding plugins, keep the set small and pinned. A defensible starter set: dsh-market, modlens (if text-only + images), one memory plugin, and optionally a workbench UI.
  3. Do a supply-chain check. Third-party plugins execute as trusted code in the harness process; no official review exists (dshpkg).
  4. Don't treat auto-review plugins as a security boundary. DSH has no security audit; plugin reviewers can be prompt-injected; keep workspace-write, pin versions, and canary-test before unattended runs.
  5. Pin and re-verify after every DSH upgrade — breaking changes are still officially expected (release notes).

Caveats

  • Official first-party pages confirmed: npm, PyPI, GitHub release notes, official docs. Everything else is community/third-party analysis labeled as such.
  • Registry counts use incompatible methods (topic, verified, curated); don't average them.
  • Star counts differ across snapshots (207k–212k over 1–5 Sep) by capture time.

Primary sources