Preface¶

The entry point for installing DSH is the dsh plugin command line. Community plugins are scattered everywhere; finding a usable one usually involves browsing directories, copying commands, and returning to the terminal to execute them; copying commands incorrectly or installing them into the wrong profile incurs a debugging cost higher than the plugin itself. The qianyumeng0228/dsh-plug-store introduced below is a host plugin. It renders the DSH plugin directory into a section within the host’s settings page and calls dsh plugin directly on the interface to complete installation, update, uninstall, and backup, eliminating the need to copy commands. The plugin is maintained by qianyumeng0228, categorized on the client side, and published on npm and GitHub.

What is this¶

One-sentence positioning: A host plugin that provides plugin store capabilities within DeepSeek Harness. It is not a standalone site, but a piece of UI hooked onto the host’s settings.section slot.

It solves three specific problems:

• There is a manual copy step between browsing directories and CLI installation; the plugin executes directly on the page.
• Whether an update actually takes effect semantically refers to the command return code, or whether the version actually changed; these are not equivalent, so the plugin judges based on the latter.
• The progress and history of installation tasks lack persistence; there is no way to review them after a restart.

The directory is built and published to GitHub Pages daily by qianyumeng0228/dsh-store. It currently收录 29,593 community plugins, of which 14,344 are ready to use out of the box.

It needs to be clear that dsh-store is a community repository with no official affiliation with DeepSeek / Synthflow. DSH’s philosophy is “Everything is a plugin,” and this repository is the community’s implementation of that philosophy.

Core Features¶

Executes installation commands for real, rather than giving you a command to run yourself. All operations are shell calls to dsh plugin targeting the correct profile, and the actual events are read back. pnpm answers “Already up to date” with exit code 0 when re-adding a dependency with a fixed version, so the update process explicitly includes the target version before reading back the currently installed version: the UI only shows “Updated” if the version actually moves; if there is no change, it shows “No change”.

Real-time progress and persistent task logs. Operations are executed as queued tasks. Progress comes from pnpm’s ndjson reporter (parse / download / link / build, current package, bytes). When a failure occurs, the 13 ERR_PNPM_* error codes are mapped to natural language prompts. Logs are written to ~/.dsh/store-data/tasks.json and remain after a restart; interrupted tasks are displayed as “interrupted” and will not disappear silently; completed and failed lines can be cleared with one click.

“Updateable” is calculated locally. The basis for judgment is the comparison between the locally installed version and the target version in the directory, not a flag field in the data. Local links and non-registry dependencies (file:, link:, workspace:, git+…) are excluded, so an update that would override them is not proposed.

Chinese-first directory. Descriptions prioritize Chinese; entries with only English are machine-translated during build (covering 99% of the published directory), and missing ones are translated on demand in the page. The Chinese / EN switch only appears when both languages actually exist.

Theme Preview Wall. Theme cards display real screenshots extracted from various repository READMEs (relative paths resolved via raw.githubusercontent.com, blob links rewritten). Only horizontal screenshots are retained; click to enter lightbox for forward/backward navigation.

Design for browsing scale. True pagination (24 / 48 / 96 per page, remembers selection), 17 bilingual categories, supports search by name / description / tags, filters include installable / official / newly added this week / updateable / favorited / installed, 7 sorts (including random), card and list views, collapsible “Recently Added” and “Most Installed” sections, bottom queue bar merges multiple installations into one confirmed batch.

Favorites, Blocking, Backup, Diagnostics. Favorites and blocking records are saved locally in the browser; Backup exports the currently installed list and its cordis patch of the current profile as readable JSON for migration; Diagnostics checks the dsh CLI, profile directory, data source, and the embedded page layout in real-time.

Only one scrollbar is retained. The page is embedded in an iframe and stretched according to the actual height of the content; scrolling is handled uniformly by the host settings column. Overlays (detail modals, queue bar, toasts, lightbox) re-anchor to the visible window on every scroll; the stretch measurement reads the end of the actual content rather than scrollHeight, so switching to a shorter tab causes the iframe to shrink back.

Installation and Enablement¶

Installation commands come from the README; the two official forms are as follows:

# npm release version
dsh plugin --profile <profile> add dsh-plug-store

# Or install directly from GitHub — no build step, zero runtime dependencies
dsh plugin --profile <profile> add github:qianyumeng0228/dsh-plug-store

As of scraping, the version published on npm is 0.1.21, while the version in the repository’s package.json is 0.1.28. The README explicitly suggests using the github: form above as a priority until the npm release catches up, as the GitHub source is always up-to-date. The license is MIT, runtime dependencies are empty, and the peer dependency is @deepseek-ai/cordis ^4.0.1.

After installation, restart the host, or let the profile’s HMR take over: the plugin declares a bundle, and dsh.bundle.patch usually reloads it without a restart.

Interface location: Settings → Plugin Store, registered on the host’s settings.section slot. The UI is also provided at /dsh-store/ via the host’s loopback port and can be opened directly in a browser.

Two usage points:

• DSH Desktop users should not use the CLI. Executing --profile web on a desktop machine writes content to profiles/web, which the Desktop application does not load, so the entry will not appear in the settings page. Desktop users should use the built-in plugin manager of the application to install.
• Which profile it acts on is resolved in the following order: profile in plugin config → profile where the plugin’s own installation directory is located (~/.dsh/profiles/<profile>/…) → DSH_PROFILE → web. Installing into desktop therefore operates on desktop.

This plugin requires a DSH host based on cordis, with development verification targeting 0.2.1-rc.2. On unsupported hosts, the settings page partition will not mount.

Typical Usage¶

After installation, open the settings page to enter the plugin store. You can operate via the following path:

1. Search within the store, filter by category, or use “Updateable” to filter for plugins installed locally but with a newer version in the directory. Each card in the list reflects the actual local state, not a static marker in the directory.
2. Click a plugin to view details (theme plugins will display screenshots extracted from the repository README). If installation is needed, click directly to install and queue it; the queue bar at the bottom of the page will merge multiple clicks into one confirmation and execute them in batch.
3. During installation, observe the progress bar and task logs; logs are also persisted to ~/.dsh/store-data/tasks.json. When a failure occurs, the log provides a prompt mapped from ERR_PNPM_*.
4. Perform updates or uninstallation on installed plugins. Uninstallation requires two-step confirmation on the interface; updates only show when a version change actually occurs.
5. When migration is needed, use the backup function to export JSON; when troubleshooting the environment is needed, use diagnostics to check the CLI, profile directory, data source, and embedded page layout.

At the command line level, the plugin itself does not introduce a new set of CLI commands; all capabilities are provided through routes under /dsh-store/.

API and Data¶

All routes are located under /dsh-store/, where api/* has access protection.

GET  /api/capabilities        Capability discovery; UI switches to host mode after seeing this
GET  /api/installed           Names, versions, types, and source repos of installed packages
POST /api/install             {source:"npm",name,version?} or {source:"github",repo,ref?} → 202 {taskId}
POST /api/update             Payload same as above; returns from / to / changed
POST /api/uninstall           Real removal, two-step confirmation on UI
GET  /api/tasks               Queued, running, and completed tasks with progress
POST /api/tasks/clear         Clears only completed and failed lines
GET  /api/backup              JSON of installed plugin list and cordis patch of current profile
GET  /api/diagnose            Health check for CLI, profile, data source, and embedded layout
GET  /data/plugins.json       Directory proxy with local cache and remote fallback

Identifiers are validated before reaching the CLI: npm sources must be package names, GitHub sources must be complete owner/repo (giving only the repo tail will concatenate an illegal github:dsh-xxx), and any value starting with - will be rejected to avoid being parsed as option arguments.

GET /api/installed returns both names and details because the display names in the directory and the local dependency keys are often inconsistent (e.g., yujunzhixue-dsh-purge in the directory is dsh-purge on disk); matching by only one would silently drop half the installed list.

Directory data is not bundled into the plugin itself. The plugin reads the directory via its own same-origin route /dsh-store/data/plugins.json and caches the snapshot at ~/.dsh/store-data/plugins.json for 24 hours, refreshing it in the background after expiration—the speed of opening the store does not depend on whether the CDN was reachable at that time. Responses use gzip negotiation and weak ETags. Snapshots are deliberately not vendored into the package to avoid distributing a fixed copy that expires every day, while the caching above provides the same initial load speed.

Security Boundaries¶

The plugin runs with the permissions of the current dsh process; you should check the plugin source code and license yourself before installing. Regarding dsh-plug-store itself, there are a few engineering constraints worth knowing:

• The api/* routes require the loopback Host (localhost / 127.0.0.1 / [::1]) and the custom header x-dsh-store: 1. Cross-site pages cannot set this header without a preflight, and it loses this preflight. The page itself and directory data remain open because they are public.
• Zero runtime dependencies, no telemetry, the only external request is fetching the directory.
• The plugin does not read any credentials; writing only occurs in ~/.dsh/profiles/<profile>/ (via dsh plugin) and ~/.dsh/store-data/ (its own task logs and data cache).

Applicability and Notes¶

Suited for a specific type of person: those who want to converge plugin discovery, installation, updates, and backup into one interface, while also requiring that the commands behind the UI are indeed executed and the results are indeed readable. If you only occasionally install a couple of plugins, the command line is sufficient on its own, so the incremental value of this plugin is limited.

A few points to note:

• Depends on a cordis host and must be compatible with @deepseek-ai/cordis ^4.0.1; the partition will not mount on unsupported hosts.
• The npm published version lags behind the GitHub source; use the github: form to get the latest fixes.
• On DSH Desktop, please use the built-in plugin manager; do not use the CLI method with --profile web.
• It installs community plugins; the directory itself is a community directory and is not equivalent to the official app store.

Closing¶

The value of dsh-plug-store lies in merging “browsing the directory” and “executing installation for real” into the same interface, and preserving progress and history via task logs. It does not reinvent a package manager; it uses the command line as is, but faithfully reads the execution results back into the interface.

Directory Page: https://www.skillhub.cn/plugins/qianyumeng0228/dsh-plug-store
GitHub: https://github.com/qianyumeng0228/dsh-plug-store