Discover, review, and install community plugins

As of 2026-08-30, pinned commit 64b4c2831fcd of Awesome DSH Plugin contains 2,666 plugin manifest files across 22 categories, spanning UI, models, memory, tools, workflows, remote access, and plugin markets. This is a repository-tree snapshot: it measures discoverability, not uniqueness, compatibility, safety, or current suitability.

Beyond plugins, the ecosystem now includes desktop clients, TUIs, Skills, MCP servers, profiles and presets, compatibility tools, and community handbooks. DSH101 selected 22 additional representative projects in this revision, bringing the ecosystem directory to 31 entry points. It is a map of useful starting points, not a leaderboard.

A directory listing proves discoverability. It is not a source audit, installation test, security endorsement, or maintenance guarantee.

Choose a discovery surface

The four main surfaces fit different stages:

Surface	Best for	What it provides
Awesome DSH Plugin	Browsing plugins that declare Bundle manifests	A 2,666-manifest snapshot across 22 plugin categories
Awesome DeepSeek Harness	Looking beyond installable plugins	Skills, MCP servers, profiles, orchestrators, clients, and resources
dsh-market	Browsing and managing plugins from Web settings	Search, categories, install confirmation, updates, and removal
dsh-find-plugin	Describing a need without knowing a package name	Topic search that returns repositories, summaries, and install commands

Installing a discovery tool is still installing a third-party plugin:

dsh plugin --profile web add dshmarket
dsh plugin --profile web add dsh-find-plugin

These commands come from the respective community repositories. DSH101 has not independently run them. Apply the same checks below before executing either one.

How this revision selected projects

DSH101 kept representative projects with a clear purpose, public source, and a verifiable entry point, then separated them by shape:

Direction	Representative entries added in this revision
Desktop and terminal	DSH Desktop, dataelement DSH Desktop, Tauri Desktop, Harness Studio, dsh-TUI
Web and workbench	dsh-web, Better Sidebar, dsh-context
Vision and local control	ModLens, dsh-image-gen, dsh-computer-use
Agents and state	dsh-agent-teams, dsh-routing-suite, dsh-knowledge-sqlite
Integration and development	dsh-lark-link, dsh-plugin-check, upstream-radar, dsh-plugin-graph
Learning and specifications	DSH Plugin Development Guide, dsh-specs, DeepSeek Harness Orange Book, broader ecosystem index

Use the ecosystem directory to filter plugins, clients, or guides and search by name, capability, or install command. Every newly added third-party project remains Listed: DSH101 checked its public description, entry point, and review date, but did not turn a project claim into an independent installation or task result.

Exclusions can also be deliberate. For example, the dsh-at-file repository now says current official releases include built-in @file and @session references, so new installations should prefer the official implementation. A general project that only mentions DSH in its README, without a clear compatibility path, is not treated as a DSH plugin either.

Check five things before installation

1. Repository and package identity

Confirm that the package name, repository, and install command agree. Inspect package.json for a dsh.bundle manifest and follow its patch file to see which modules it loads. A package without a Bundle manifest can be installed as a normal dependency but does not contribute an active configuration layer.

2. Installation scripts

A GitHub dependency supplies source code. TypeScript plugins often use prepare to build after installation. pnpm 10 and later block that script by default until the Profile’s pnpm-workspace.yaml explicitly allows the package under allowBuilds.

That authorization runs code outside the agent sandbox. Read prepare, the scripts it calls, and their dependencies before allowing it. A successful installation is not evidence that the code is safe.

3. Runtime capabilities

Plugin code runs inside the Harness process. It can register services, events, and tools, and may access files, credentials, and the network visible to that process. Tool approvals govern agent tool calls; they do not automatically isolate the plugin’s own code.

Prefer focused plugins with explicit configuration boundaries. Apply stronger review to remote access, shell, credential, automatic update, and message-forwarding plugins.

4. A reproducible version

Pin GitHub installation to a full commit so later upstream pushes cannot silently change the code you run:

dsh plugin --profile review add github:owner/repository#<full-sha>

Record the repository, commit, review date, and approved build scripts. Pin npm packages too, and confirm that the registry package is maintained by the repository you inspected.

5. An isolated first run

Use a separate review Profile, disposable checkout, or container for the first installation. Do not start in an environment containing real secrets or uncommitted work. Inspect the final composition before a minimal task:

dsh --profile review --dump-config
dsh --profile review

Confirm the added layers, network listeners, file writes, and unload behavior before moving the plugin into a daily Profile.

Give every candidate an evidence level

DSH101 uses four levels so that “seen” does not become “verified”:

1. Listed: a directory link exists; source has not been reviewed.
2. Source reviewed: entry points, manifests, scripts, and primary permission boundaries were inspected.
3. Install checked: installation and removal completed on a recorded system and version.
4. Task checked: a minimal real task produced the expected result with environment, command, and date recorded.

Every newly added community project, along with dsh-market and dsh-find-plugin, remains Listed in the ecosystem directory. DSH101 checked public descriptions, install or download entry points, and repository state, but has not labeled them independently installed or task tested.

Remove first when something goes wrong

Remove a plugin from the test Profile:

dsh plugin --profile review remove <package-name>

Run --dump-config again and confirm that the Bundle layer is gone. Removing the dependency cannot guarantee cleanup of files an installation script wrote outside the Profile directory, which is another reason to perform first-run verification in a disposable environment.