DSH plugin market: install via npm, GitHub, or dsh command

A plugin missing from the DSH plugin market is not necessarily uninstallable — the market only indexes public GitHub repositories tagged with dsh-plugin, so everything else goes through custom install. DSH Plugin Hub turns custom install into three input cards: npm package, GitHub source and dsh command. Below is when each card applies, which formats it accepts, and which input is blocked before it ever runs.

DSH plugin custom install overview

Market listing is the result of proactive scanning plus human review, not a full inventory of every plugin, so "I cannot find it" is normal rather than a fault — custom install is the door left open for plugins outside the catalogue. How to open and browse the market, filter by category and search is covered in browsing the DSH plugin market, and the three sources compared from the command line in where to install DSH plugins from. This article answers one question only: when the plugin you want is not in the market, how do you get it into the current profile safely?

Why the DSH plugin market cannot find your plugin

Because listing has hard boundaries: the repository must be a public GitHub repository and must carry the dsh-plugin topic before the site can scan it and add it after review. The market currently indexes 8,000+ community plugins, sourced from user submissions and proactive scanning — if any step is missing, the plugin stays invisible. Before installing, check three things:

1. Open the repository URL and confirm it is a publicly accessible GitHub repository (a private repository is invisible to everyone and cannot be installed);
2. Check the About section for the dsh-plugin topic — that is the official discovery channel, and a repository without it will not be scanned;
3. Search again with a different term: market search covers plugin names, descriptions and tags, so searching the repository or owner name beats searching a generic feature word.

If all three are fine and it is still missing, the repository is either too new to have been scanned or is not an installable plugin package (a demo, or a notes repository). In that case install it through custom install first — custom install only cares whether the package can go into your profile, not whether the market lists it. Once indexed, it appears in the market as a catalog plugin.

Choosing among the three DSH plugin custom install channels

The choice is not about plugin type but about what you already hold: an npm package name goes to the npm card, a GitHub URL to the source card, and an official command or an update of an installed target to the dsh command card. The entry point is the Custom Install page of DSH Plugin Hub. Each card accepts exactly one format, so a mismatch is reported in place instead of making you guess how the address should be installed.

Channel 1: npm package

Use this when the plugin is published to npm and you want the prebuilt package with no local build. The card accepts three forms:

1. A bare package name, such as @scope/pkg, one per submission;
2. A regular install command — npm install <pkg>, npm i <pkg>, pnpm add <pkg> or pnpm install <pkg> — installed into the current profile, one at a time;
3. The official global form npm install -g <pkg>, which installs a system-level CLI and does not appear in the installed plugin list.

It does not accept a GitHub URL (that belongs to channel two) or a token starting with -, which npm would read as a flag rather than a package name.

Channel 2: GitHub source

Use this when the plugin only ships source and has no npm release yet; the trade-off is that dependencies are installed and the package is built. The card accepts github:owner/repo, https://github.com/owner/repo, git+https://github.com/owner/repo, [email protected]:owner/repo, and a bare owner/repo.

Set one expectation first: a git distribution only contains what the repository committed. If the author committed source but not the build output, the install completes yet the plugin has no entry file and will not load. What to do about that is covered in the last section.

Channel 3: dsh command

Use this when you copied an official command from the plugin documentation, or when you want to update an installed target to the latest version. This card accepts the one official form:

dsh plugin --profile <name> add <target>

--profile is a required long option with no -p shorthand — omitting it is an error — and the --profile=<name> form works too. Only the verbs add and update are allowed (update overwrites an installed target with the latest version). Uninstall is not on this card; it is done from the Installed list.

In the official CLI this command means "forward the arguments to pnpm inside the profile directory selected by --profile <name>". In other words it is equivalent to running pnpm add <target> in that profile directory, except the CLI aligns the path and profile for you.

The standard flow for one custom install

1. Pick the card on the Custom Install page that matches the format you hold. Expected: the matching channel passes the format check, while a mismatch is stopped outright;
2. Paste the target (package name, repository URL or full command) and wait for the format check — if it fails you get the recommended format and no request is sent. Expected: only after the check passes does Hub resolve the install method;
3. In the confirmation dialog, verify the plugin name and the method about to run, then confirm. Expected: nothing is written to the profile before you confirm;
4. Watch the live progress in the dialog, then find the plugin in the Installed list filtered by the manual-install source. Expected: a plugin mounts only after the host restarts, so restart when the dialog offers it.

DSH Plugin Hub's Custom Install turns the three channels into three input cards, each with its own example syntax line and format hints — unrecognised input is stopped outright, with no request sent:

When a plugin is not in the catalogue, or you just want to try one temporarily, the Custom Install page of DSH Plugin Hub beats typing commands by hand: each channel shows its own format hints, and everything installed there lands in the Installed list tagged as a manual install.

DSH plugin pre-install checks: which input is blocked and why

A custom install runs third-party code, so three gates are in place: the client format check rejects invalid input, the server entry-file check rejects repositories missing their build output, and a post-install check catches what slipped through. In detail:

1. Format check (client) — each card has its own format rule; input that does not belong to that channel is flagged in place with a red field, and no request is sent, so a typo never triggers a real dependency install;
2. Entry-file check (server, GitHub source channel only) — the default-branch commit is resolved, the source archive for that commit is downloaded, and the entry declared in package.json is confirmed to exist inside the archive; if it is missing, the install request is rejected instead of producing a plugin that installs but cannot load. npm packages are trusted from the registry and pass straight through, with the post-install check as a backstop;
3. Post-install entry check — even when the install command exits 0, the main / exports target inside the plugin's node_modules package is verified to exist; if it does not, the task fails and the pending restart is revoked, so the host is not left unable to start;
4. Channel switches (Settings → Security) — the npm, GitHub and dsh channels can each be turned off, which disables the matching card and points you to Settings; turning off a channel you never use reduces the sources of executable code at the root;
5. Build-script confirmation — installing from GitHub source requires you to confirm whether a dependency's build script may run; allow it only for repositories you trust, as explained in how to install DSH plugins safely.

DSH plugin caveats and limits

1. Manual installs are managed differently from catalog plugins: plugins installed by custom install carry a manual-install source tag and can be filtered as their own group in the Installed list;
2. Private repositories do not work through the GitHub source channel: it only handles publicly cloneable repositories, and Hub does not carry credentials on your behalf;
3. npm install -g stays out of the installed list: it installs a system-level CLI that does not travel with a profile, and npm itself handles removal;
4. Prefer the prebuilt npm package: the GitHub source channel depends on committed build output, and a missing artifact means a missing entry file — when an npm release exists, use channel one;
5. Versions move: DeepSeek Harness is in developer preview and the official repository states that breaking changes will come (source), so treat the command forms and wording here as the current state of the official CLI and Hub.

Sources: deepseek-ai/deepseek-harness, dsh-plugin.org plugin market, dshplugin/dsh-plugin-hub