What is pax-beehive/dsh-hub-cli?

DSH Hub CLI treats a local DeepSeek Harness setup as a content-addressed Release you can diff, apply and roll back. It is useful when several people or CI runners must share the same plugin order and patch, and awkward when you only need one plugin.

Can I use pax-beehive/dsh-hub-cli commercially?

Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.

Is pax-beehive/dsh-hub-cli still maintained?

Yes. The repository last received commits 3 days ago.

What programming language is pax-beehive/dsh-hub-cli written in?

Mainly TypeScript, according to GitHub's language statistics.

dsh-hub-cli: share and apply DSH Presets

At a glance

What is it?: DSH Hub CLI treats a local DeepSeek Harness setup as a content-addressed Release you can diff, apply and roll back. It is useful when several people or CI runners must share the same plugin order and patch, and awkward when you only need one plugin.
Who is it for?: Adopt dsh-hub-cli if more than one machine or a CI runner has to end up with the same DSH plugin order, patch and pinned versions, and you want a diff before anything is swapped in. Skip it if you only install one or two plugins by hand, or if you cannot put Node.js 22.13+ and pnpm on the machine.
Can I use it commercially?: Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?: Yes. The repository last received commits 3 days ago.
What is it written in?: Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

Hysen Labs Editorial · September 17, 2026 · pax-beehive/dsh-hub-cli

The problem dsh-hub-cli solves: a DSH setup is not just a plugin list

A DeepSeek Harness profile is a runtime version, a set of plugins at specific versions, the order they load in, a cordis.patch.yml that wires them together, and environment variables holding keys. The README frames the usual alternative as a wiki page, a Slack thread and an afternoon of "works on my machine". That is the gap this project targets.

The CLI turns that directory into a first-class artifact. The README describes a Preset Release as a small, content-addressed document whose hash the CLI verifies before doing anything with it. The audience is therefore narrow and specific: teams running DSH locally who need a colleague, a CI runner or an AI agent to reproduce the same harness, and who care about which commit of a GitHub-sourced plugin is actually loaded. If you run DSH alone and install plugins by hand, the machinery here is more than you need.

What a Preset Release contains, and why the ordering matters

The README breaks a Release into four parts. Runtime pins the exact DSH version the author verified against. Bundles are ordered, npm sources carry sha512 integrity hashes, and GitHub sources must point at a full 40-character commit rather than a branch. Patch is the author's cordis.patch.yml, published verbatim. Inputs declare which environment variables the Preset needs.

The ordering constraint is the interesting design decision. Load order is stored in the Release and validated on apply, so two machines cannot silently disagree about which plugin wins. Pinning GitHub sources to a commit rather than a branch is the same instinct applied to source resolution. The cost is that a Preset is deliberately not live: it records what the author had, and the README is explicit that this is not "whatever is latest today".

Inputs deserve a closer look. The README states that only ${ENV_VAR} references are published and values stay local, and that the CLI refuses to publish a patch containing a credential-looking value. That is a heuristic, not a guarantee. A credential in an unusual format could still pass the check, so reviewing the dry-run output before publishing is worth the minute it takes.

Installing dsh-hub-cli and applying your first Preset

The README requires Node.js 22.13+ and pnpm on your PATH. The package is published on npm as @dsh-plugin-hub/cli, so a global install is the documented entry point.

bash

npm install --global @dsh-plugin-hub/cli
dsh-hub --help

After that, --help should list the available command groups. The next step is finding a Preset to try. The README's search example looks for the word workspace.

bash

dsh-hub profile search workspace

Before changing anything, the README suggests a diff against a named local profile. This is the command that tells you whether the Preset is safe to apply on your machine.

bash

dsh-hub profile diff dsh-web-workspace --version 0.1.0 --profile web

Apply is described as staged, validated and then swapped in atomically, so a failure partway through should not leave the profile half-written. The command takes the same slug, version and profile arguments.

bash

dsh-hub profile apply dsh-web-workspace --version 0.1.0 --profile web

Finally, the README uses doctor to confirm the profile is healthy after the swap.

bash

dsh-hub profile doctor --profile web

Sharing your own setup follows the same shape, with a dry run first. Publishing non-interactively in CI uses a publish-scoped token in DSH_HUB_TOKEN instead of an interactive login.

bash

DSH_HUB_TOKEN=dshhub_... dsh-hub profile share my-stack --version 1.0.0 --profile web

Reviewable plans are the core mechanism, and also the main friction

The README states that nothing changing your local harness runs immediately: the CLI first writes a plan, an exact description of what it intends to do. Apply is staged and validated before an atomic swap. Rollback restores the previous complete revision, and history lists the saved revisions.

bash

dsh-hub profile history --profile web
dsh-hub profile rollback --profile web

This is a coherent model, and it is the reason the tool can be used by people who did not author the Preset. It also means every operation is at least two steps if you want to be careful: diff, then apply. For a single plugin, the README offers a shorter path that skips the Preset machinery entirely.

bash

dsh-hub search memory
dsh-hub info dsh-context --version 1.2.3
dsh-hub install dsh-context --version 1.2.3 --profile web

The README does not document what happens when a plan is interrupted between staging and the atomic swap, nor how long previous revisions are retained before history is pruned. Those are the two questions I would want answered before relying on rollback as a safety net in CI.

Where dsh-hub-cli is the wrong tool

Two constraints stand out. First, the client is only half the system: the README says the website, API and registry live at dshpluginhub.ai, and this repository is the open-source client for the Hub. Without network access to that registry, publishing and applying Presets have nowhere to go. A fully air-gapped DSH installation cannot use the share and apply flow as documented.

Second, the tool is opinionated about how plugins enter a profile. If your team already pins plugins through its own lockfile and considers load order an implementation detail, a Preset Release duplicates that responsibility in a second place, and the two can drift.

There is also a versioning seam worth knowing about. The npm package is @dsh-plugin-hub/cli and the README's latest release entry is v0.2.0, while the workspace package.json in this repository carries version 0.4.0. Anyone reading the repository to judge the CLI's maturity should check which of those numbers the published package actually has before drawing conclusions.

How this differs from a plain plugin installer

A conventional plugin installer resolves the latest satisfying version at install time and writes the result into a local manifest. That is the right model when you want updates and do not care which exact build arrived.

dsh-hub-cli inverts it. A Preset Release is immutable, content-addressed and verified before use, npm bundles carry sha512 integrity hashes, and GitHub bundles must name a full commit. The unit of sharing is the whole profile, including the patch file and the declared environment inputs, not one package. Upgrading is an explicit act with a diff: the README shows dsh-hub profile upgrade --version 0.2.0 --profile web --dry-run before the real run.

The trade-off is freshness. A Preset will not pick up a plugin release published after the author captured it, which is exactly the point, but it does mean someone has to re-share the profile when the team wants to move. There is no documented automatic re-resolution step.

Maintenance, licence and upgrade cost

The repository is not archived and the last push was on 2026-09-15, so this is a project that is still being worked on. It is MIT licensed, which places few restrictions on reuse and redistribution; that is a factual note about the licence identifier, not legal advice, and anyone embedding the CLI in a commercial product should read the LICENSE file themselves.

Upgrade cost has two parts. The CLI itself is an npm global install, so upgrading means reinstalling @dsh-plugin-hub/cli, and the workspace pins pnpm@10.33.0 with node >=22.13.0 in its engines field. The Presets you publish are separate artifacts with their own versions; moving a team to a new plugin set means someone re-shares the profile, and everyone else runs upgrade with a dry run first. The repository also ships a check script that chains typecheck, node --test, pack:check and governance:check, which tells you what the maintainers expect a contribution to pass.

Editorial conclusion

Adopt dsh-hub-cli if more than one machine or a CI runner has to end up with the same DSH plugin order, patch and pinned versions, and you want a diff before anything is swapped in. Skip it if you only install one or two plugins by hand, or if you cannot put Node.js 22.13+ and pnpm on the machine. Before trusting it, run dsh-hub profile share --dry-run on your own profile to see exactly what would be captured, and check that your secrets appear only as ${ENV_VAR} references.

Frequently asked questions

What does DSH stand for in dsh-hub-cli?

The README expands it as DeepSeek Harness, and refers to a local setup as a DSH profile throughout. The CLI, schemas and resolver in this repository are the open-source client for DSH Plugin Hub.

How do I install dsh-hub-cli?

The README requires Node.js 22.13+ and pnpm on your PATH, then installs the package globally with npm install --global @dsh-plugin-hub/cli. Running dsh-hub --help confirms it is on your PATH.

How do I roll back a Preset applied with dsh-hub-cli?

The README lists dsh-hub profile history --profile web to see saved revisions and dsh-hub profile rollback --profile web to restore the previous complete revision. It does not document how long those revisions are kept.

Can dsh-hub-cli publish a Preset from CI without an interactive login?

Yes. The README shows setting DSH_HUB_TOKEN to a publish-scoped token and running dsh-hub profile share with a slug, version and profile argument, instead of running dsh-hub login first.

Official sources

Community notes