Jingyun DSH Client: a Tauri shell and paid-agent storefront for DeepSeek Harness

What the Jingyun DSH Client actually adds to DeepSeek Harness

DeepSeek Harness is an open source AI conversation runtime with a plugin architecture. On its own it gives you a chat surface and an extension mechanism. It does not give you user accounts, a payment path, or a place to sell what you built on top of it. Jingyun DSH Client is aimed squarely at that gap. The README describes it as a client that turns agents, skills and workflows into tradeable goods, and the pitch is that an AI developer can package an agent as a standalone commercial product in about thirty minutes.

The intended user is a solo developer or small team that has already built something on DSH and now needs a storefront, a login, and a way to charge for tokens. The README lists the commercial loop as membership, subscription payment, compute quota control, asset distribution and private-domain operation. That is a business stack, not a developer tool. If you only want to talk to a model, this is a lot of surface area for no benefit.

Inside the monorepo: a Tauri shell, a React plugin and an embedded runtime

The repository is a pnpm monorepo with two halves. The first is packages/jingyun-dsh, a TypeScript branding plugin. Its src directory splits into client (React components, modals, pages and a styles.ts that injects global styles), agent (an agent package manager), routes (HTTP handlers for the plugin market, agent API and membership), config (a loader that talks to the Jingyun platform) and common. The second half is src-tauri, a Tauri v2 shell written in Rust, with src/lib.rs handling backend process management, the system tray and windows.

The interesting part is what ships inside the shell. src-tauri/resources/vendor/ is meant to hold embedded Node.js, Python and Git runtimes, and resources/splash/ holds an HTML splash screen. That means the packaged desktop app does not depend on whatever Node the user happens to have installed. The trade-off is size and supply: the README states the runtime packages are large and are not included in the Git repository, and that you have to join the community group to receive them. A fresh clone therefore cannot produce a working desktop build until you obtain that payload and drop it into src-tauri/resources/vendor/.

Data flow is conventional for this shape of app. The Rust process supervises a DSH backend, the React plugin renders inside the DSH web surface, and routes/ proxies market, agent and membership calls to the Jingyun Studio backend identified by the domain field in desktop-config.json. The plugin market reads a registry snapshot bundled at packages/jingyun-dsh/resources/registry-snapshot.json rather than querying GitHub live.

Installing @jingyun-ai/jingyun-dsh into an existing DSH instance

If you already run DSH, the README recommends the npm route rather than cloning the repository. Install the plugin package:

npm install @jingyun-ai/jingyun-dsh

Then copy the example config and rename it. The README is explicit that you do this yourself, the file is not generated for you:

cp packages/jingyun-dsh/desktop-config.example.json packages/jingyun-dsh/desktop-config.json

Edit desktop-config.json to point at your tenant. The README gives exactly these three keys:

{
  "domain": "http://your-domain/",
  "custom_name": "Your App Name",
  "custom_logo": "https://your-logo-url.png"
}

The domain is what the routes layer uses to reach the Jingyun platform. The README says you can register at jingyun.studio to get a domain without standing up your own backend, which tells you the membership and payment logic lives on their servers, not in this repository. After enabling the plugin in your DSH configuration, the login, membership and payment surfaces appear inside your existing DSH UI.

For the full desktop build the README gives a different sequence. Clone, install, build, then run the packaging console:

git clone <repo-url>
cd jingyun_dsh
pnpm install
pnpm build
run_pack.bat

The README lists Node.js 18 or newer, pnpm 8 or newer, stable Rust for the Tauri shell, and Python 3.8 or newer for the Tkinter packaging console. run_pack.bat opens that console and lets you set the brand name and domain interactively before producing an NSIS installer.

Web development mode and the localhost:3080 surface

You do not need to build the desktop shell to work on the plugin. The README documents a web path. Build the plugin, then start the DSH web service:

pnpm build
pnpm start

It states that browsing to http://localhost:3080 gives you the running interface. The package.json shows pnpm start runs node scripts/run_dsh.js, and a separate pnpm dev script runs the plugin watcher and the DSH server concurrently with --watch-path pointed at packages/jingyun-dsh/lib. That watch path is a useful detail: the plugin compiles into lib, and the server reloads from there, so editing React sources without running the plugin build leaves you looking at stale UI.

The desktop path is pnpm tauri:dev, and production packaging is either pnpm tauri:build or the GUI console. Note that the README marks the GUI console as recommended specifically because it exposes the brand name, logo and tenant settings. That is a hint about where the intended workflow sits: the command-line build is the fallback, not the happy path.

The vendored runtime is the real distribution constraint

The largest practical limitation is stated plainly in the README: the embedded Node.js, Python and Git runtimes are not in the Git repository, and you are directed to the community group to obtain them. Everything else in the build chain is reproducible from the clone. That one directory is not.

This has consequences beyond convenience. You cannot audit what you are shipping by reading the repository alone, because a significant part of the shipped binary comes from a file you receive out of band. For a commercial product that you intend to sell, that is a supply chain question you should answer before you brand anything. The repository does include scripts/prepare_vendor.js and a download:runtimes script in package.json, which suggests the payload is assembled from downloads, but the README does not document that path as the supported one.

The second constraint is platform. The README describes Windows throughout: run_pack.bat as the packaging entry point, NSIS for the installer, and a .bat file as the one-click build. There is no mention of a macOS or Linux installer. Tauri v2 supports other targets in general, but nothing in this repository's documentation claims them, and the packaging console is a Python Tkinter script invoked from a batch file.

The third is the backend dependency. Membership, subscription and compute quota all run against the Jingyun Studio platform. The README does not document a self-hosted alternative or an offline mode for those features. If jingyun.studio is unreachable or your tenant is suspended, the commercial half of the client has nowhere to go.

How this differs from shipping plain DSH with your own billing

The obvious alternative is to run DeepSeek Harness and integrate a payment provider yourself. The difference is scope, not quality. DSH gives you the runtime and the plugin API. You would then build accounts, subscription state, quota accounting, a market listing page and a distribution mechanism, and you would own the schema for all of it. Jingyun DSH Client hands you those pieces already wired together, at the cost of routing them through Jingyun Studio's backend and accepting its data model.

A second alternative is a generic desktop wrapper such as a plain Tauri or Electron shell around your own web UI. That gets you a native window and an installer, and nothing else. There is no membership system, no market, and no agent package manager. The Jingyun client's agent/ directory and its bundled builtin-skills (wecom-connector, feishu-connector, agent-manager, skill-creator) exist to make agents installable and manageable as units, which a generic wrapper does not attempt.

The choice comes down to whether the Jingyun platform's commercial layer matches how you want to charge. If you need per-token metering with a quota system, the built-in compute credit model is closer to done than anything you would assemble quickly. If you need a billing shape the platform does not support, the integration is a liability rather than a shortcut, because you would be fighting a layer you do not control.

Licence, maintenance and what an upgrade actually costs

The README states the project uses the Apache License 2.0 and links to a LICENSE file, and the badge at the top says the same. The repository's top-level file listing does not show a LICENSE entry, so confirm the file is present before you rely on the grant. The README also separates third-party licensing: DSH follows its original open source licence, the builtin-skills follow theirs, and the plugin registry snapshot follows its own because the data comes from third-party communities. Those are three different obligations in one product. This is a description of what the README says, not legal advice; if you plan to sell a branded build, have someone check the vendored runtimes and the registry snapshot separately.

The README carries an explicit disclaimer that the plugin registry is third-party data and that the software provides display and installation only, with no warranty of safety, compliance or availability. That is a meaningful boundary for a product you would put your own brand on.

On maintenance, the repository is not archived and the last push was on 2026-09-15. The release history shows v0.1.15 on 2026-09-10, v0.1.16 on 2026-09-11 and v0.1.17 on 2026-09-14, which is a fast cadence for a project at version 0.1.x. The package.json release script uses bumpp to bump version numbers across package.json, packages/jingyun-dsh/package.json, src-tauri/tauri.conf.json and src-tauri/Cargo.toml together, with a cargo update for the client crate. That tells you upgrades touch both the JavaScript and the Rust sides in lockstep, so a partial bump is not the intended path. Upgrading also means re-verifying your desktop-config.json against whatever the config loader expects, since the README documents only three keys and does not describe a migration path between versions.

Editorial conclusion

Adopt it if you already run a DeepSeek Harness instance and want membership, subscription billing and a plugin market without building those yourself, or if you need a white-label Windows installer and can supply the vendored Node.js, Python and Git runtimes. Do not adopt it if you need a Mac or Linux desktop build, if you cannot accept a closed Jingyun Studio backend for accounts and payments, or if you want a plain DSH UI without a storefront. Before committing, verify three things in the repository: whether a LICENSE file actually exists at the root, whether src-tauri/resources/vendor/ can be populated without joining the WeChat group, and whether desktop-config.json is read at build time or at runtime, because that decides whether one binary can serve several tenants.

Frequently asked questions

Official sources

1. Issues
2. jingyunstudio/jingyun-dsh on GitHub
3. Project website
4. README
5. Releases