The dsh-web project has published an all-in-one plugin package for DeepSeek Harness Web, giving developers a single installation path for task automation, remote browser access, SSH administration, image analysis, skins and other interface extensions. The consequence is a much broader DSH Web workbench—and a larger set of packages and security boundaries for its operator to manage.
The recommended package, @linxin666/dsh-web-all, installs through DSH’s web profile. Developers who do not want the complete bundle can install individual plugins instead. A companion catalog at dsh-market.com distributes plugins alongside skins and virtual pets.
This is better understood as an attempt to make DSH Web an extension host than as a collection of interface decorations. The profile mechanism keeps plugins out of DSH’s source tree, but it does not remove the operational cost of combining code from npm, Git repositories and external maintainers. dsh-web reduces assembly work; it does not eliminate dependency or trust decisions.
One profile carries UI features and host operations
The project says every bundled component mounts through DSH’s official profile mechanism. That is a sensible boundary: plugins can be installed, replaced or removed without patching the host, while skins remain asset directories loaded by a dedicated skin plugin. An upgrade to DSH therefore need not require rewriting a theme integration.
The bundle reaches well beyond presentation. Its task board has five columns and can submit work to an actual DSH agent session, then update the card after execution. Cron schedules run through the DSH Web host rather than the browser, so closing the tab does not stop them. The documented limit is important: triggers missed while the host is stopped or the machine is asleep are skipped rather than queued for later execution.
Other packages add paired mobile and PC access, an SSH operations panel, Git history visualization, conversation recovery and a describe_image tool. The image tool sends referenced images to a configured OpenAI-compatible vision endpoint and places only the returned text in the conversation record. The bundle also integrates the external dsh-better-sidebar plugin, while its older aionui-panel has stopped receiving maintenance and is scheduled for removal.
This breadth makes the aggregation package convenient, but ownership becomes less obvious. The documentation distinguishes bundle-prefixed configuration IDs from IDs used by separately installed copies of the same plugin. It says loading both sources avoids duplicate registration but provides no additional benefit. Operators still need to know which copy supplies a feature before changing its configuration or upgrade path.
The installation notes expose the same tension. The repository documents pnpm layouts that can hide nested packages from DSH, build-script approval requirements for cloudflared, cpu-features and ssh2, and a pnpm 11 release-age policy that can select an older package even when @latest is requested. In the documented failure case, an older skin loader can leave DSH Web unable to start because a referenced package is missing. These are recoverable package-management problems, but an aggregation layer concentrates their effects.
dsh-market.com joins discovery directly to installation
dsh-market.com is produced from the same repository and catalogs skins, pets and plugins. The Web GUI includes a workshop card that can browse the catalog, install skin and pet assets into the DSH home directory, and send plugins through the plugin manager. Skins can be previewed without committing them to disk.
The catalog itself has a deliberately narrow architecture. A static build script generates it from skin.json, pet.json and community.json; pushes to the main branch trigger deployment. Dynamic likes run through a Cloudflare Workers API backed by D1, with one vote allowed per device. Items are ranked by device-based popularity, and the top three in each category appear on the home page.
That structure makes the catalog inputs identifiable and keeps social ranking separate from the static asset metadata. It does not make popularity a security signal. A device vote says that an item attracted approval, not that its package lifecycle, install scripts or maintenance status have been reviewed.
The repository explains how authors contribute, how catalog data is built and how users install packages. It does not describe a formal security-review or package-approval process for workshop entries. That omission matters because the workshop is not merely a screenshot gallery: it shortens the route from discovering an extension to running it inside a developer workbench.
Remote access and SSH define the real trust boundary
The remote plugin provides the clearest evidence that dsh-web must be assessed as operational software. It pairs a phone or another PC browser by QR code or link, using a one-time, time-limited token. Unpaired devices are denied workspace data, and stopping the service revokes paired devices. Public access can be added through a Cloudflare tunnel.
The project also warns against marking a tunnel domain with --trusted-host when using its pairing route. According to the documentation, that option lets the SDK’s /api path bypass the plugin’s pairing gate. This is a precise and useful warning, but it means the advertised access control depends partly on how the surrounding DSH service is launched.
Real-time updates use Server-Sent Events. The documentation says Cloudflare Quick Tunnels and Tailscale Serve do not carry those events, so the plugin falls back to polling. Messages still work, but new updates may arrive several seconds late. Tunnel selection therefore changes behavior even when ordinary HTTP requests appear healthy.
The SSH plugin raises a more direct security concern. It offers an xterm.js terminal, SFTP transfers, localhost-only port forwarding, concurrent commands across filtered host groups and agent access to the same host configurations used by the panel. Those are substantive administration capabilities.
Its disclosed storage model is correspondingly consequential: SSH passwords and private-key passphrases are kept in plaintext in ~/.dsh/dsh-ssh.json, protected by 0600 file permissions. The project also warns that reconnecting can replay non-idempotent commands and that remote output is returned without redaction.
dsh-web’s plugin architecture keeps extensions separate from DSH source and makes a broad workbench easier to assemble. Its unresolved trade-off sits at the workshop boundary: the closer discovery gets to one-click installation, the more the ecosystem needs trust and maintenance signals that are stronger than package availability and device likes.
