dsh-gui

🌐 English | 中文

DHS (DeepSeek Harness) Electron GUI client: wraps the web-UI workflow into a native desktop GUI, keeping the DHS kernel maximally untouched.

DHS is delivered officially as a web UI (browser). dsh-gui uses Electron to host the same DHS frontend, turning "open a webpage in your browser" into "a desktop app" — with zero changes to the DHS kernel.

Download

Get them from GitHub Releases. The first launch automatically installs bundled DHS dependencies (with an optional China mirror for speed); no manual environment setup required.

System Requirements

• Windows 10+ (x64): portable build (zip) — see Download above
• macOS 14+ (Apple Silicon / arm64): dmg installer — see Download above
• Run from source: any platform via pnpm install && pnpm dev (see Quick Start below)

Features

• Native desktop experience: standalone window, system tray (minimize-to-tray on X, quit from tray context menu), single-instance lock, DeepSeek blue-whale icon
• Dynamic port: the host starts with dsh web --port 0; the GUI parses the readiness URL and loads it, avoiding port-3080 conflicts
• First-run setup wizard: 5-step flow (welcome → download source → download progress → real verification → done), China mirror / official source / system proxy selectable, real progress shown throughout
• Bundled distribution: the packaged build bundles Node + pnpm + DHS source + built-in plugins; first launch auto-installs dependencies — out of the box
• Built-in plugin system: 5 bundled plugins (plugin discovery / Skill manager / MCP manager / global proxy / About) covering DHS's daily management and extension — see below
• Plugin agent awareness: every built-in plugin registers a systemPrompt section with the host, so the model is aware of installed plugins and what they do each session — no manual prompting needed
• Global proxy: configure system proxy / manual proxy graphically in Settings; the GUI injects environment variables at launch so the whole DHS chain (LLM calls / built-in search / MCP client) goes through the proxy
• Bilingual zh/en: UI language follows the system, switchable manually, and mapped to DHS kernel locale.preference (kernel UI follows)
• Security baseline: the main window may only navigate to the local host origin; external links open in the system browser; dangerous permissions are denied by default; the wizard page ships a CSP
• Install logs: the full install process is written to %APPDATA%/dsh-gui/install.log for failure tracing
• Zero kernel changes: the DHS kernel stays officially untouched; the GUI is only a shell

Built-in plugins

dsh-gui bundles 5 plugins. Except for dsh-about, all are standalone open-source repos, distributed with the packaged build and auto-registered to the DHS profile on first install:

dsh-discovery — plugin discovery & LLM audit

Positioned as a community-plugin discovery and LLM-audit tool: DHS has no official plugin marketplace, and third-party plugins are essentially executable code, so it is deliberately read-only — it only handles "discover → filter"; security review is delegated to the LLM (one-click generation of an audit prompt; the LLM reads the source and checks for risk; install if it passes, stop if risk is found).

• Browse: pulls all plugin repos under the GitHub dsh-plugin community topic (bounded pagination + timeout fallback)
• Categorize: 7 functional categories + Other (UI enhancement / terminal / tools / memory / models / notifications / development)
• Scenarios: 5 use scenarios (writing / development / model integration / automation / notification integration) with automatic dedup and limited recommendations
• Search: a 38-word Chinese-English synonym table so Chinese keywords hit English plugin data
• LLM-audited install: one-click audit prompt for the LLM (reads source / checks deps / identifies malicious behavior); if it passes, dsh plugin add installs; if risk is found, it lists the risk points and stops. Official (deepseek-ai) badge, installed marker, and update checks also carry security review (diff old vs. new, update only if it passes)

Full design notes (security model, fetch rules, scenario filtering) are in the repo's README.

dsh-skillmanager — skill management

DHS's skill system has no centralized registry — files are the registry: drop <name>/SKILL.md into a scan root and the host auto-discovers it and adds it to the model's available directory (~/.dsh/skills, ~/.agents/skills, and 3 more scan roots). This plugin presents that system graphically: skill list, grouping, enable/disable (frontmatter permission switches), guided creation, LLM review. Skill creation and editing are executed by the host agent (LLM); this plugin handles "see clearly, control firmly".

dsh-mcpmanager — MCP management

DHS's MCP has no standalone store — one server = one @deepseek-ai/dsh-mcp-client plugin instance, persisted in ~/.dsh/profiles/web/cordis.patch.yml. This plugin provides form-based CRUD for MCP server config (stdio / streamable-http transports); saving applies via hot reload (new sessions see the tools immediately, no restart) and offers LLM verification guidance.

dsh-proxy — global proxy

DHS's network stack uses raw fetch() end-to-end and does not read the Windows system proxy; Node 24+ supports the NODE_USE_ENV_PROXY env-var proxy (bootstrap-only security design — .env cannot set proxy vars). This plugin adds a "System Proxy" row in Settings → General Settings, persisted to ~/.dsh/settings.yaml; dsh-gui injects env vars at launch so LLM calls / built-in search / MCP client all route through the proxy.

dsh-about — About

The "About" tab in Settings (built-in plugin, shipped in this repo, not published separately) shows four layers of version info — dsh-gui / kernel / runtime (Electron + Node) / installed plugins — handy for version checks and troubleshooting.

Plugin agent awareness (systemPrompt sections)

Every built-in plugin registers a systemPrompt section on the host side (plugin:<id>), injected into the model context each session. The model thus naturally knows which plugins are installed and what each one does — e.g. when the user asks "what plugins do I have?", the model answers directly from the registered descriptions, no extra docs needed.

Architecture

┌─────────────────────────────────────────────┐
│ Electron App (dsh-gui)                       │
│  main process ──spawn──> DHS host subprocess │
│     │                    └─ apps/cli/bin.js  │
│     │                        --profile web   │
│     │                        --port 0        │
│     │                        → 127.0.0.1:<p> │
│  BrowserWindow loadURL ←─────────────────────┘
└─────────────────────────────────────────────┘

• GUI shell: Electron (window, tray, process management, setup wizard, single-instance lock)
• DHS host: runs the official dsh as a subprocess (bundled Node 24 in packaged builds, system Node in dev), kernel 100% untouched
• Communication: local HTTP + WebSocket (127.0.0.1; the port is assigned dynamically via --port 0, avoiding conflicts with an already-running DHS on 3080)
• Config: ~/.dsh (shared DHS home, used by both web and GUI modes)

⚠️ Known boundary: DHS's cordis loader depends on a Node internal API (node-addon-require-builtin), which is incompatible with Electron's bundled Node — so the host runs as a subprocess rather than in-process (see docs/ARCHITECT.md).

Quick start (development)

# Dependencies (workspace includes ../deepseek-harness)
pnpm install

# Build DHS (first time only: host lib + client lib + web dist)
pnpm --filter @deepseek-ai/dsh-root run build

# Pre-commit checks (format first, then check)
pnpm format
pnpm typecheck && pnpm check && pnpm test

# Launch
pnpm build && pnpm start

Packaging

Windows (local build)

One-click script (recommended; full console output):

build-win-unpacked.bat

Or manually (package.json scripts):

pnpm package:dir   # portable build → release/win-unpacked/
pnpm package       # nsis installer → release/dsh-gui-setup-*.exe

Released versions: GitHub Releases.

macOS (build from source)

dsh-gui is a workspace project: the kernel dependency deepseek-harness must sit next to dsh-gui (both pnpm-workspace.yaml's ../deepseek-harness and the icon source apps/web/public/favicon.svg resolve relative to that layout):

# Layout: two repos side by side
#   ~/dev/dsh-gui
#   ~/dev/deepseek-harness
git clone https://github.com/EricXu20266/dsh-gui.git
git clone https://github.com/deepseek-ai/deepseek-harness.git

cd dsh-gui
pnpm install                                    # install deps (incl. DHS workspace packages)
pnpm --filter @deepseek-ai/dsh-root run build   # build the DHS kernel (lib + web dist)

# Run in dev mode (uses the system Node; no bundled runtime needed)
pnpm build && pnpm start

# Package the macOS app (Apple Silicon; outputs release/*.dmg + *.zip)
node scripts/gen-icons.mjs                      # generate mac icons (icon-512.png)
pnpm exec electron-builder --mac --arm64 --publish never

The packaged build bundles a Node + pnpm runtime under resources/runtime/ (gitignored — prepare it yourself): download the darwin-arm64 Node from nodejs.org and the pnpm tarball from the npm registry, extracting each into the matching folder.

Packaged-build layout: resources/runtime (bundled Node + pnpm), resources/dhs (DHS source seed, no node_modules), resources/dsh-* (four standalone plugin repos + built-in dsh-about). On first run the wizard copies the DHS source to %APPDATA%/dsh-gui/dhs (macOS: ~/Library/Application Support/dsh-gui/dhs) before installing dependencies, so the app never writes into its own Resources directory.

Directory layout

dsh-gui/
├── electron/        # GUI shell engine (main/host/installer/proxy/paths/tray/preload/renderer)
├── plugins/         # built-in plugins (dsh-about; the other 4 are standalone repos)
├── mac-packing-resource/  # sources of the 4 external plugins for single-repo macOS CI packaging
├── platform/        # platform adapters (windows packaging / macos reserved)
├── resources/       # assets (icon, packaging runtime: bundled Node + pnpm)
├── install/         # installer config
├── scripts/         # build/package scripts
├── tests/           # unit tests (node:test + tsx)
├── tools/           # helper tools
└── docs/            # docs system (ARCHITECT/DEV-TRACKER/index...)

Full docs: docs/index.md.