dsh-web: a plugin ecosystem for the DeepSeek Harness web GUI

The gap dsh-web fills in the native DSH web GUI

The README states the position plainly: the native DeepSeek Harness web interface covers conversation and tool calls, and leaves multi-task scheduling, long-running background execution, mobile collaboration and engineering operations to extensions. dsh-web is that extension layer. It is aimed at people who already run `dsh web` and want a task board, a phone client, an SSH panel or a Git graph without forking the host.

The comparison table in the README lists what the full bundle adds over the native interface: per-model capability declarations for image input and reasoning tiers, a multi-column task board with cron execution, QR-code device pairing with SSE sync, an SSH panel covering terminal, transfer, tunnel and cluster, token and balance statistics, a right-hand panel for files, editor, terminal, Git and browser, a branch selector with commit history graph, and centralized session archiving with bulk archive, restore and delete.

The scope is wide, and that is the first thing to weigh. This is not a single tool. It is a collection of plugins plus a skin system plus a market site, packaged so that one install command can pull the whole set or you can pick individual packages.

How the plugin mounting actually works

The mechanism is the official DSH profile system, not a fork. The root `package.json` declares a `dsh.bundle.patch` key pointing at `./packages/dsh-web-all/cordis.patch.yml`, and the only runtime dependency is `@linxin666/dsh-web-all`, pinned at `0.3.23`. The README describes this as zero-modification mounting: the patch file is applied to a profile, and the host source stays untouched.

That design has a consequence worth stating. Because the bundle is delivered as a patch layer plus npm packages, upgrading means moving the pinned version and letting the profile re-apply the patch. The desktop client documentation says its auto-initialized profile carries a marker, is redeployed when the built-in runtime upgrades, and preserves a user's custom patch layer without touching profiles the user created. For a command-line install, that redeployment logic is the desktop app's job, so you own the patch layer yourself.

The desktop client takes a different route to isolation. It runs its own dsh host on ports 3082-3181, separate from the 3080/3081 range the native `dsh web` uses, so a desktop instance and a command-line instance can run side by side with independent sessions. Both share `~/.dsh` for global config, session history and keys.

Installing dsh-web and running a first scheduled task

The README points at the aggregation package `@linxin666/dsh-web-all` for a one-shot install of the full feature set, and at the per-package READMEs for installing a single plugin. The desktop client is a separate download: the `dsh-desktop-*` assets attached to each GitHub release, with macOS dmg/zip and Windows exe/zip builds.

For the command-line path, the bundle is declared in the project's own `package.json`, so the practical first step is to confirm your DSH version satisfies the requirement shown in the README badge, `>=0.1.5-rc.1`, before adding anything.

npm view @linxin666/dsh-web-all version

That prints the published version of the aggregation package. If it resolves to `0.3.23`, you are looking at the same version this repository pins. If it fails to resolve, the package is not reachable from your registry and nothing downstream will work either.

Once the plugin set is mounted and `dsh web` is running, the task board is the most direct way to see the system do real work. The README describes the flow: open the task board from the sidebar, click execute on a card, and a real DSH agent session runs the task and writes the status back to the board. Clicking the card jumps to the session to review the full interaction.

Scheduling is configured in the task detail view with a cron expression. The README gives two examples, a daily 23:00 DSH upgrade check and a Monday 09:00 weekly report. The host process fires the schedule even with the browser closed and stores the result. There is also an optional anti-sleep power setting, off by default, that keeps the machine awake while the display can still turn off; the README lists Windows, macOS and Linux with systemd-logind as supported.

Remote control, SSE and the tunnel that breaks it

The mobile remote plugin is the part most likely to disappoint in a specific, documented way. Pairing works by scanning a QR code or copying a link from the device panel at the bottom of the sidebar. The phone browser loads the official web GUI with a touch layer: tap the whale icon for the sidebar, swipe to collapse or expand, long-press a session for its menu, Enter inserts a newline, and inputs use 16px text to stop focus zoom. Panels meant for a desktop screen, including SSH, the task board and the Git graph, are hidden on mobile.

The same pairing channel accepts a second desktop browser, which then runs the full desktop GUI. Communication is gated through the `/remote/api` path; unverified access is blocked and shown only a banner. Pairing tokens are single-use and expire, and a stop button revokes all connected devices.

The failure mode is spelled out in the README. Mobile receives streaming messages over Server-Sent Events. Cloudflare quick tunnel (trycloudflare.com) and Tailscale Serve do not pass SSE through by default. In those environments the plugin falls back to high-frequency polling: messages still send and receive, but new messages may be slightly delayed. If you want immediate streaming, the README points at a Cloudflare named tunnel or self-hosted TCP port forwarding. It also warns against setting `--trusted-host` for a tunnel domain, because that bypasses the device verification gate.

Where dsh-web is the wrong choice

Two constraints are stated outright. The desktop installers are not commercially code-signed. On macOS the first launch hits a security prompt and the README's workaround is right-click then open; on Windows SmartScreen appears and the documented path is More info then Run anyway. If your environment blocks unsigned binaries, the desktop client is not an option and you are back to mounting the bundle on your own `dsh web` instance.

The second constraint is reach. Every plugin here extends a DSH web host. There is no standalone mode, no CLI-only variant and no headless server described in the README. If you do not run `dsh web`, none of this applies to you.

There is also a scope cost. The aggregation package pulls in the full feature set, and the README notes it already pre-integrates a community plugin, `dsh-better-sidebar`. A team that wants only, say, the Git graph has to work through the per-package READMEs instead of taking the bundle, and the bundle's pinned version then has to be tracked separately from the packages you actually use.

How this differs from a DSH TUI or a plain terminal workflow

A terminal or TUI workflow keeps everything in one process with no browser, no profile patch and no asset layer. dsh-web goes the other way: it assumes a browser GUI as the surface and adds capabilities that need a persistent host, which is exactly why cron execution survives closing the browser.

The concrete difference shows up in the task board. A shell cron job runs a command and appends to a log. The task board runs a real DSH agent session, writes the outcome back to a five-column board (to plan, to do, in progress, done, failed), and lets you click through to the session transcript. It also offers session reuse: if the previous run's session is still alive and idle, the host reuses it, reapplying the task's permissions and model while keeping context history; if the session has closed, it creates a new one.

That is a meaningfully different model from a cron entry, and it is also more machinery. If your scheduled work is a fixed command with a predictable exit code, the board adds a host process, a session lifecycle and a board state to maintain. If your scheduled work is an agent task whose transcript you want to inspect later, the board is the reason to use this project at all.

Licence, upgrade cost and what the repository enforces

The licence is Apache-2.0, declared in the repository root and shown in the README badge. That is a permissive licence with an explicit patent grant and a requirement to preserve notices and state changes. It says nothing about the assets distributed through the market site, which the README describes as a separate distribution channel for skins, pets, plugins and community agent presets. If you plan to redistribute a skin, check that asset's own terms rather than assuming the repository licence covers it. This is a description of the licence text, not legal advice.

The upgrade surface is visible in the repository layout. The root `package.json` pins `@linxin666/dsh-web-all` at `0.3.23`, and the release history shows a fast cadence: v0.3.21 on 2026-09-12, v0.3.22 on 2026-09-13, v0.3.23 on 2026-09-16. The last push to the repository was on 2026-09-16. Frequent releases mean the pinned version drifts quickly if you do not bump it deliberately.

The scripts in `package.json` also tell you what the maintainers expect to break. There are check scripts for aggregation, the skin center catalog, skin hooks, the community index, runtime dependencies, lib artifacts, i18n and docs, plus an end-to-end mount test at `scripts/e2e-mount.sh`. Running `pnpm test:mount` exercises the mount path directly, which is the check most likely to catch a bad patch layer before you apply it to a working profile.

Editorial conclusion

Adopt dsh-web if you already run `dsh web` and want task scheduling, mobile access or SSH tooling without patching the host. Skip it if you need a signed installer or your tunnel cannot carry SSE. Verify the DSH version against the `>=0.1.5-rc.1` requirement and confirm your tunnel type before pairing a phone.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. zhu1090093659/dsh-web on GitHub