This article is derived from the plugin's already-indexed fields (wiki / faq / compatibility_json / readme), not freshly generated by AI. Source field is noted at the end of each section.

Quick start

dsh-web-ui

— source: plugin_wiki.wiki_content

Install & verify

dsh plugin --profile web add github:zhu1090093659/dsh-web-ui#path:packages/dsh-web-ui-all

Run the command above in your DSH Web Profile. Then enable the plugin in the plugin list.

— source: plugins.install

Key points

• Web 终端：xterm.js 远程终端，实时输出，窗口大小自适应；
• 文件传输：SFTP 上传 / 下载，有进度条，能浏览远程目录；
• 端口转发：本地隧道直连远程内网服务（数据库、API、管理后台），只监听 127.0.0.1；
• 集群执行：一条命令并发跑多台主机，按别名 / 环境 / 标签过滤；
• Agent 直连：Agent 和面板共用同一份主机配置，对话里说一句「连一下 xxx 看看状态」，智能体就去执行远程命令。

— source: plugin_wiki.readme_en (fallback readme_raw)

FAQ

What needs to be done after installation for the plugin to take effect?

Restart dsh web. If using source code development mode, in addition to dsh plugin add, you also need to run pnpm install && pnpm -r build && node scripts/link-profile.mjs, and restart dsh web after installation for it to take effect (README.md:24-30).

What if I only want to install one or two plugins, not the entire bundle?

Simply install the corresponding standalone sub-package directly (e.g., dsh plugin add @linxin666/dsh-client-ui-task-board), no need to go through this bundle; installing this package will activate all sub-plugins and cannot select only some of them (README.md:38).

Will there be conflicts when installing with a same-named standalone plugin package?

No. This package unifies aggregated row IDs with the web-ui- prefix (e.g., web-ui-task-board), while standalone installations still use the original ID (task-board), and the loader no longer rejects duplicate IDs. It is recommended to keep only one source; having both provides no additional benefit (README.md:39).

How should configuration entries written by plugin ID in the profile correspond?

Use the web-ui- prefix when the plugin comes from this bundle (e.g., the autoTunnel config entry for remote-web-ui is written as web-ui-remote-web-ui), and use the original plugin ID for standalone installations (README.md:39).

After upgrading to a new version, the new version doesn't take effect. How to troubleshoot?

After changing the package.json version number in the profile and running pnpm install, top-level node_modules/@linxin666/* entries may still link to the old version store directory. Need to confirm these links point to the new version (Windows: cmd /c rmdir then cmd /c mklink /J ), then restart dsh web (README.md:32-34).

What custom logic is actually installed in this package code?

The host side has no business logic (the apply in src/index.ts:14 is an empty function); the browser side only has a compat shim (src/client/index.ts:1-98) that adds legacy data-pane / data-dsh-frame attributes to dsh web shell sidebar/middle/detail three-column containers, allowing child plugins mounted with old selectors to continue working.

Will this package still work after the official dsh web shell is upgraded?

Yes. The compat shim uses MutationObserver to listen for DOM changes and merges/reapplies attributes in the next frame (src/client/index.ts:60-71). After React re-renders and rebuilds the column containers, attributes are automatically restored; it's idempotent and won't trigger repeatedly.

— source: plugin_wiki.faq_json

Compatibility

• DSH: 未声明（package.json 无 dsh.engines；DSH 版本通过 @deepseek-ai/* SDK 依赖隐式锁定）
• Node: ^22.19 || >=24（据 packages/AGENTS.md:9，本包 package.json 未声明 engines）

— source: plugin_wiki.compatibility_json

Pitfalls

Review the upstream repo before installing. This guide is auto-derived from indexed fields and may lag the latest release. If anything contradicts the official docs, treat the upstream source as authoritative.

— source: general rule