dsh-market logo
dsh-market
English | 中文
The plugin market inside DeepSeek Harness. On dsh 0.2.1+ it is a tab on the Plugins page, right next to Installed; on older hosts open Settings → Plugin Market. Browse, search, one-click install.
📡 The same catalog is also a plugin market index. On dsh 0.2.1+, open Plugins → Discover → Index sources and add https://cdn.jsdelivr.net/npm/dsh-plugin-catalog/index.json. That is this list as a format-1 index, served from npm so it loads quickly everywhere — dsh gives a source 15 seconds, and the GitHub Pages copies (https://awesome-dsh-plugin.com/index.json and https://dshmarket.com/index.json) can exceed that from some networks. The host's Discover tab and the plugin_market agent tool then search it.
dsh-market
One-click themes: install, switch live, no restart.
Install
-
Official DSH Desktop: Open Settings → Plugins in the app, search for
dshmarket, and install it through the app's plugin manager. No command line
is needed.
-
Regular dsh web: Run this command, then restart dsh web:
dsh plugin --profile web add dshmarket
-
Custom profile: Replace web in that command with your host's actual
profile name: dsh plugin --profile <profile> add dshmarket. Follow your
host's restart instructions.
-
From the GitHub source (no build): add github:dsh-market/dsh-market
makes pnpm ask before running the package's build scripts. The prebuilt
tarball attached to the same release installs without that step:
dsh plugin --profile <profile> add https://github.com/dsh-market/dsh-market/releases/download/v<version>/dshmarket-<version>.tgz
On a machine with DSH Desktop, running dsh plugin --profile web add dshmarket
may report success but installs the market into profiles/web, not the
profile used by the Desktop app. It will not appear in Desktop. Install through
the app's Settings → Plugins instead; Desktop's profile is managed by the app.
Once it is installed, open the Plugins page and pick the Plugin Market
tab next to Installed (dsh 0.2.1 and newer — plain dsh web included, no
desktop app needed). The market is also still a section of Settings → Plugin
Market: on dsh 0.2.0 and older that is the only way in, and from 0.2.1 the
Settings dialog lives in the account menu. If you would rather reach it in one
click from anywhere, the market can also put its own Plugin Market row in
the sidebar; turn it on from the market's card under Plugins. All three
entries can be switched individually under Advanced in that card, and the
market refuses to close the last one. Going the
other way, an installed plugin's ··· menu offers View in Plugins on
dsh 0.2.1+: it opens the host's own page for that plugin, which is the only
place its individual rows can be switched one by one.
Requires dsh web 0.1.0-rc.6 or newer. On an older host the market
disables itself and says so in the browser console rather than rendering
against primitives that are not there — if the Plugin Market entry never
appears, that is usually why. Worth checking when a desktop build bundles
its own dsh: it may be older than the one npm would give you (#139).
What you get
-
Browse & search the full community catalog (4200+ plugins, growing daily) — category filters, star counts, top/new sorting, bilingual descriptions that follow your UI language
-
Host-aware discovery — cards show the DSH requirement declared by engines.dsh or lockstep @deepseek-ai/dsh-* peers; the compatibility filter hides only confirmed mismatches with the running host. GitHub-only entries read the linked package's manifest, including monorepo subdirectories; Release downloads read the selected release tag, including the current tag behind latest/download. Undeclared, malformed or unavailable requirements stay unknown and visible. Public manifest facts are cached; compatibility is evaluated against the running host
-
Screenshots — AppStore-style screenshots, auto-carousel when there's more than one, click to preview full-size: author-curated shots show right on the card (zero extra requests); plugins without curated shots fall back to automatic README extraction once you open the install dialog. Images load from GitHub hosting only
-
Comments — every card opens the plugin's discussion thread in place. It is the same thread its pages on dshmarket.com and the catalog show, so a plugin has one conversation rather than three. Backed by GitHub Discussions through giscus: it loads when you open it, needs a GitHub account only to post, and the note above it says plainly that opening it contacts giscus.app and GitHub. On local dsh web, reading stays embedded while a dedicated GitHub action opens the exact discussion in a new tab for sign-in and posting, so the cross-site return never carries or depends on the host session
-
Favorites — bookmark plugins and themes from Discover or the Themes tab; a dedicated Favorites tab lists them with search, sort, and install actions. Bookmarks persist in the profile's market state (state.json); entries that leave the catalog can be cleared in one click
-
Groups — organise installed plugins into named groups (rename, delete, and per-group search); a plugin lives in one group and ungrouped is the default. A group carries its own switch: all-on, all-off, or the mixed state its members are really in, so a working set can be switched as a unit without touching the rest. A group holds at most one theme. The grouping itself is local state in the profile's state.json
-
Notes — write your own one-line description for any installed plugin and it replaces the author's on that row, so a shelf of forty plugins answers "why did I install this" in your words. Stored locally beside groups and favorites, never sent anywhere
Speed
Installs prefer repo-verified npm packages, then author-supplied prebuilt GitHub Release tarballs, before falling back to full-repo GitHub source downloads. Prebuilt installs are typically seconds and do not need local build scripts; source-only plugins depend on your connection to GitHub.
Security
-
Installs are restricted to sources listed in the curated awesome-dsh-plugin registry — anything else is rejected
-
Build scripts stay blocked by default (pnpm ≥10); allowing one is your explicit per-package choice
-
Terminal/CLI-surface plugins are flagged before you install them into the web profile
-
The install endpoint accepts same-origin POST only; the market never phones home
-
Backups can contain credentials from your profile config — the UI warns before export and upload; WebDAV sync is https-only, refuses private-network targets, and never stores your password in the browser
-
Authenticated Gist requests always go directly to api.github.com; bearer tokens are never sent to a public GitHub acceleration service. GitHub source archives also stay on canonical codeload URLs so pnpm's integrity policy remains in force
-
The restart endpoint additionally requires a direct loopback client (forwarded requests are rejected) and relaunches the exact DSH entry, arguments, environment, and working directory
-
One-click restart launches a detached replacement. When this host is systemd's own service process the button is hidden automatically — the market would otherwise kill the takeover process along with the unit's cgroup and the service would not come back. The pending-change notice stays visible and says so. Detection requires both a systemd marker AND being the unit's main process, because INVOCATION_ID is inherited by every descendant of a unit (an ordinary terminal included) and hiding the button for those would be the worse bug. pm2 and launchd are not detected, so those deployments need the explicit setting below. Either flip Allow restart off in Settings → Plugins → Plugin configuration, or write it into the profile patch — where it has to sit under config:, because the loader passes only that sub-object to a plugin and a top-level allowRestart: is silently ignored (#227 by @Fantasymax):
- id: dsh-market
name: dshmarket
config:
allowRestart: false # NOT at the top level beside `name:`
On dsh 0.1.7 and newer there is no switch to flip: the host derives a plugin's settings from its own Config schema and no longer serves a plugin-registered settings namespace, so the market has no control there. The profile patch below is the way on every host.
GET /dsh-market/status reports "restart": false once it has taken effect.
-
Plugins that compile (native modules) build under the environment the dsh process inherited — which a GUI, a systemd/launchd unit, or a Windows Start-menu launch does inherit from your shell. If a plugin needs a newer compiler than the machine's default ( too old while other work depends on that version), pin the build-time variables with under — the config equivalent of from a terminal, without changing anything globally. Pinned values may override inherited ones but never the or the market computes for its children (issue #336):
Submit your plugin
This repo is the market app, not the catalog. The plugin list comes from the curated awesome-dsh-plugin registry — to get your plugin listed in the market, open a PR there (one entry in the list; the site and this market pick it up automatically, usually within a day). Please don't PR plugin entries against this repo.
Roadmap & feedback
- Bugs go in issues — attaching the market's "Export log" makes diagnosis roughly ten times faster
- Feature ideas go on the Roadmap. Issues are kept for things that are broken, so a proposal filed as an issue gets moved there and closed; the discussion stays where you wrote it either way
- Every roadmap item welcomes community PRs — say so on the item before starting, so two people don't build it twice
Data source
Catalog statistics preserve their source: npm counts cover the stated 30-day window; GitHub-only releases can show lifetime downloads of all public repository Release assets, including packages, checksums and companion files. The counts are never added together or called installations/users. Tooltips include the available collection time; npm-download sorting keeps its existing window. Catalog host declarations are accepted only for the exact pinned install URL, with the existing on-demand manifest lookup retained for older catalogs.
Fetched live on every open from awesome-dsh-plugin.com/plugins.json — curated entries, npm mapping, and star counts refreshed daily by CI, with no stale cache behind it. A failure reports the actual reason and elapsed time, with a Retry button.
There is deliberately no bundled snapshot to fall back on: for a catalog that grows daily, a stale answer is not a degraded one but a wrong one — a plugin published this morning would read as "does not exist".
In the China download region the same catalog is read from npm first, through the same region-aware routes the plugins themselves arrive on: every China mirror already carries it, it comes off the mirror rather than bouncing back to the origin registry, and it carries a version, so a bad catalog build can be rolled back instead of only being fixed forwards. The origin stays last in the list as the route that has always worked. Region detection happens once and the answer is remembered; Settings → Plugins → Plugin configuration can override it.
If that host is unreachable from your network, point the market at a mirror. Set DSHM_REGISTRY_URL in the environment dsh runs in, to anything serving the same plugins.json shape:
DSHM_REGISTRY_URL=https://your-mirror.example/plugins.json dsh web
Friends
DSH Desktop (dataelement)
dsh-desktop — a desktop app for DeepSeek Harness: run and manage a local Harness without installing Node.js yourself. Ships with this plugin market preset as the default. dshdesktop.com
DeepSeek Harness Desktop (hairyf)
deepseek-harness-desktop — a native desktop app for DeepSeek Harness built with Tauri (Rust + Web): one-click local install and launch with no Node.js setup required. On first run it offers to install this plugin market as a recommended preset.
DeepSeek Harness Desktop (anywhere-labs)
deepseek-harness-desktop — an Electron desktop app for DeepSeek Harness built around the idea that everything is a plugin, including the desktop itself: profile switching, a bundled Node and pnpm, and a recoverable install path that snapshots the profile before a change. dshdesktop.cn
DSH App
dsh-app — a DeepSeek Harness desktop client built on Tauri 2 rather than Electron, so it ships a much smaller binary and uses the system webview. AGPL-3.0.
Local DSH
local-dsh — a DeepSeek Harness desktop client that can run the model on your own machine: it bundles llama.cpp next to Node, pnpm and DSH, so a downloaded GGUF model answers without any external API. Built on Tauri; Apple Silicon Macs for now. localdsh.com
dsh desktop (MochiNek0)
dsh-desktop — a cross-platform DeepSeek Harness desktop client built on Tauri (Windows, macOS, Linux). It uses the system webview, so the installer is a few megabytes: 2.3 MB on Windows, 5.8 MB on macOS. It starts dsh web in the background on launch and embeds it in a native window, sharing sessions and config with the CLI. This market sits first in the recommended list of its built-in plugin panel, one click to install. A Runtime panel enumerates and switches the machine's Node installs and installs or upgrades dsh, no administrator privileges required, and native notifications fire when a turn ends or dsh is waiting on you. dsh-desktop.cc.cd
DSH Get
DSH Get — a searchable web directory for discovering DeepSeek Harness plugins: category filters, bilingual descriptions, install commands and per-plugin detail pages. Its normalized catalog snapshot is public at bobby-sheng/dshget-data.
modlens
modlens — the first vision plugin for DeepSeek Harness: bolts visual understanding onto text-only models like DeepSeek and GLM. Paste an image, get structured JSON evidence back — OCR, layout, semantics. Available right in this market:
dsh plugin --profile web add @liustack/modlens
License
MIT · dshmarket.com
