dsh-top
用于 dsh Web GUI 的系统监控工具：在浮动、可折叠面板中实时显示 CPU、RAM、磁盘、网络和占用资源最多的进程。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:glenngit/dsh-top#cacbdf570894ee25a13b5c9e57ca6dedb2e99c83
Top 以 dsh-top 发布，当前版本为 0.1.1。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A plugin for the DeepSeek Harness (DSH) web GUI: a system monitoring tool that shows live system stats in a floating, collapsible panel pinned to the top-right corner.
os.cpus() tick deltas) + core countos.totalmem() / os.freemem())– / + buttonps, awk, head, …) are filtered out of the top-processes list| Part | File | What it does |
|---|---|---|
| Host half | lib/index.js | Registers GET /api/dsh-top-stats; CPU + memory use Node os APIs with container-aware cgroup overrides; disk, network and processes use per-platform collectors that degrade to null when unavailable. |
| Browser half | lib/client.js | dsh.client web bundle; registers the panel into the frame-wide shell.overlay slot; polls every 2 s (pauses while collapsed). |
| Composition | cordis.patch.yml | The dsh.bundle patch layer that inserts the loader entry. |
DSH host code runs on Linux, but the DSH server can be run on any OS Node.js supports. dsh-top is multi-platform: it always reports at least CPU + memory (Node os, no subprocess), and fills in disk / network / processes where the platform allows. Missing sections are shown as n/a in the widget rather than failing the whole request.
| Platform | CPU | MEM | DISK | NETWORK | PROCESSES |
|---|---|---|---|---|---|
| Linux | ✅ | ✅ | df | /proc/net/dev | ps |
| macOS | ✅ | ✅ | df | netstat -ib | ps (BSD) |
| Windows | ✅ | ✅ | PowerShell Get-PSDrive | PowerShell Get-NetAdapterStatistics | PowerShell Get-Process† |
| Containers (cgroup) | ✅* | ✅* | df* | /proc/net/dev* | ps* |
| Other / unknown | ✅ | ✅ | n/a | n/a | n/a |
† Windows process CPU is a lifetime-average percentage — Get-Process.CPU (cumulative CPU seconds) divided by process age, the same semantics Linux ps pcpu reports — and MEM% is derived from the real RSS bytes, not the raw working-set value. Every external collector (ps, df, powershell, …) runs with a 5 s timeout, so a wedged tool degrades its section to n/a instead of hanging the request.
* Container support is container-aware and graceful:
--memory, a Kubernetes limit, systemd unit limit), the MEM meter reports the container's limit and current usage (cgroup v2 memory.max/memory.current, or v1 memory.limit_in_bytes/usage_in_bytes) instead of the host's total. On an unlimited cgroup it falls back to the host os.totalmem() view.cpu.max quota/period, or v1 cpu.cfs_quota_us/period_us), the core count reflects the quota; otherwise it uses os.cpus().length.max, v1 CFS -1, and the ~2^63 bytes v1 memory.limit_in_bytes reports on an unrestricted root — so an unrestricted host is never misread as having exabyte-sized RAM.df/ps still report CPU + memory; the missing DISK/NETWORK/PROCESSES sections render as n/a.The CPU + memory meters work on every Node platform. Disk, network and process meters depend on the listed command/pseudo-file being present — otherwise those sections render as n/a while the rest keep working.
npm test
Runs a zero-dependency suite (node --test) over the pure collector parsers with realistic fixtures: Linux (df, /proc/net/dev, ps), macOS (netstat -ib, BSD ps), and Windows (PowerShell JSON output — including the CPU-seconds→percentage and RSS-bytes→percent conversions), plus the cgroup file parsers (memory.max, cpu.max, CFS quota, and the "no limit" sentinels) and the live container memory/CPU fallback contract. The macOS/Windows parsers are verified here without needing a live Mac or Windows machine — only the thin command-execution wrapper around them is platform-bound.
Because it is a system monitor, the host half reads host-wide CPU, memory, disk, network and process state. The cross-platform core (CPU + memory) uses Node's built-in os module — no subprocess and no OS-specific pseudo-files. Linux /proc reads go through Node's own fs.readFileSync. Only the platform collectors that need system tools invoke them — ps, df, and on Windows powershell — every time via execFileSync with a static argv array (never a shell string, no shell -Command interpolation of untrusted data), so there is no shell-injection surface and no attacker-controlled input. On Windows the PowerShell sub-command is a fixed script literal; none of its values come from the HTTP request. No data leaves the host, no credentials are read, and every read is read-only.
dsh.so's static scanner flagsnode:child_processas "critical". That is a heuristic signal on the mere presence of process access — not a vulnerability. Process access is intrinsic to a monitoring tool; review the (small) source yourself: the collectors are platform-whitelisted, argument-confined, and read-only, and any failure degrades to "n/a" rather than failing the request.
dsh plugin --profile web add dsh-top
Then restart the web app and refresh the page — the panel appears at the top-right.