dsh-market is shipping a browser-based plugin market for DeepSeek Harness that can browse a catalog, install plugins, check updates, alter load order and export backups from the DSH web interface. The immediate consequence is that adding a DSH plugin no longer has to begin at a terminal or end with manually reconciling configuration files.
That is a useful change, but “market” understates what this project is trying to become. Its README describes an operational layer over a local DSH profile: it writes disable rules, can trigger a replacement process when a restart is necessary, stores backups, and exposes diagnostics about conflicting bundles and dependency versions. The project’s real value will depend less on its catalog UI than on whether those control-plane actions remain legible and conservative.
The repository is explicit about a key boundary. dsh-market is the application, not the catalog. Listings come from the curated awesome-dsh-plugin registry, with a live JSON feed and an offline snapshot fallback. That arrangement separates discovery from the market client, but it also means the client inherits the registry’s judgments and its failures.
A plugin browser with state-management responsibilities
The visible feature set is familiar: category filters, search, star counts, top and new sorting, bilingual descriptions and install dialogs with screenshots. The repository says the catalog contains more than 1,250 plugins and is growing daily. It also has a dedicated theme area, where themes take effect immediately, are mutually exclusive, persist across restarts and can be removed to revert the selection.
The more consequential features appear after installation. dsh-market offers per-plugin update checks, a bulk update action, uninstall controls and hot enable/disable toggles. For the latter, it writes disabled: true or false entries into the profile’s cordis.patch.yml, described as DSH’s official patch layer. The README says DSH recomposes through hot-module replacement in roughly one second and reapplies the selected state at boot.
That approach is materially better than treating plugins as opaque packages. A plugin interface that only installs code shifts the difficult work to the user when versions collide, order matters or a plugin must be temporarily taken out of service. dsh-market at least tries to surface those conditions: its diagnostics page identifies duplicate loader entries, dependency-version mismatches, multiple core-package versions, overrides and invalid configuration. Its load-order tool can propose an ordering from plugin before and after rules, but it says it will not write the change until a trial composition succeeds.
This is the project’s strongest design decision. It treats plugin installation as a configuration change with consequences, rather than as an app-store transaction that ends at a green checkmark. The pre-apply explanation of order changes—overrides, invalid entries and duplicates—is especially important because load order is the sort of detail a one-click UI otherwise hides until it breaks something.
There are limits to that promise. The diagnostic and ordering features can identify known configuration surfaces; they cannot establish that independently developed plugins behave safely together. The README’s own warning that a listing is not an endorsement is therefore not boilerplate. The market reduces setup friction, but it does not turn third-party code into trusted code.
Convenience is bounded by the host and the source list
dsh-market requires dsh web version 0.1.0-rc.6 or newer. On older hosts, it disables itself rather than rendering against absent primitives; the README says this can show up as a missing Plugin Market entry, particularly where a desktop build bundles an older DSH version. The project also says self-management through the Settings plugin configuration area needs 0.1.0-rc.7 or newer.
Those version gates are easy to overlook because the product is positioned as a visual shortcut. They are a reminder that this is not a standalone marketplace client. It is a plugin embedded in a host whose web primitives, desktop packaging and process model matter. A user who sees no UI may be dealing with compatibility rather than a catalog or account problem.
The installation path has similarly deliberate boundaries. dsh-market says it prefers npm tarballs when a plugin is published to npm, after checking the registry mapping against the repository to prevent name squatting. GitHub-only plugins remain dependent on GitHub downloads. More importantly, installs are restricted to sources listed in the curated registry; other sources are rejected.
That restriction is a defensible trade. A marketplace that accepts arbitrary repository URLs would be more flexible, but it would also make the polished install flow a distribution mechanism for any code a user pastes in. Restricting sources limits discovery to the registry’s scope and review process. It does not make listed plugins safe, but it prevents the market interface from silently becoming a generic remote-code installer.
The README adds several useful friction points. Build scripts remain blocked by default under pnpm 10 or later, with explicit per-package permission needed to allow one. Terminal or CLI-surface plugins are flagged before installation into a web profile. Missing pnpm can be detected and set up through the interface. These details suggest the project understands that installation failures and package scripts are not edge cases; they are part of the product boundary.
Backups and restart controls need the same scrutiny as installs
The backup feature illustrates both the ambition and the risk. dsh-market can export a profile’s plugin list and configuration as readable JSON, import it on another machine, store it on WebDAV with daily automatic backups, or synchronize through a private GitHub Gist. Restore operations merge rather than discard plugins installed after the backup, validate before writing and roll back on failure.
Those are sensible safeguards for a tool that modifies local state. Yet the project also warns that profile configuration can contain credentials, and warns users before exports or uploads. WebDAV synchronization is restricted to HTTPS, rejects private-network targets and does not retain the password in the browser. This is appropriately cautious, but it leaves an unavoidable trade-off: portability grows precisely when configuration leaves the machine.
Restart handling is another area where dsh-market avoids pretending every operation can hot-load. When a change requires a restart, the interface can show a pending-change banner with a one-click action. The repository says this endpoint accepts same-origin POST requests, requires a direct loopback client and relaunches the exact DSH entry with its arguments, environment and working directory. It also advises disabling the restart action when DSH is managed by systemd, launchd, pm2 or another supervisor.
That is a narrower design than a generic “restart now” button, and it should be. Process supervisors own lifecycle policy for a reason. The market can identify pending work and offer a local convenience path, but it cannot know whether a developer’s environment expects a supervisor to perform replacement. The unresolved question is whether users will recognize that boundary before a smooth web control starts competing with the process manager that is supposed to remain in charge.
Top comments (0)