dsh-desktop-kit
DeepSeek Harness (DSH) 的自有桌面外壳：一个小型插件，可在原生 Tauri 窗口中打开网页界面——真正的 macOS 全屏（带装饰窗口）、单实例，以及关闭窗口即关闭 Harness 的生命周期。无托盘，不捆绑 Chromium。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:MDR-EX1000/dsh-desktop-kit#6e8103115709269386bb5e0353725b6ad53f2548Desktop Kit 以 dsh-desktop-kit 发布，当前版本为 0.2.6。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
Self-owned desktop shell for DeepSeek Harness (DSH): a small plugin plus a native Tauri window over the harness web surface. The macOS arm64 release package includes the native shell and clickable DSH.app launcher.
dsh web starts → the plugin spawns the shell on the served loopback URL → you get DSH in a real desktop window. You can still use the browser as a second client by opening the loopback URL yourself; the desktop app does not open that extra browser window during a cold launch. No fork, no repackaged runtime, no second profile — everything stays a plugin over your existing harness.
dsh-desktop is great and was the blueprint. We rebuilt a smaller one for one concrete reason: real macOS fullscreen. Its window is frameless with a web-drawn title bar and never wires up setFullscreen — the maximize button is zoom, not a native fullscreen Space. This shell uses a plain decorated window, so the green traffic-light button and Ctrl+Cmd+F give you true macOS fullscreen out of the box.
0.1.2-rc.1; the visible URL becomes clean after the exchange.~/.dsh/bin, and the clickable DSH.app is installed on the first dsh web start; no Rust build is required. Launching the app does not open Terminal.app.target="_blank" / cross-origin links are delegated to the system browser via the shell's kit_open_external command (a bare WKWebView renders them dead otherwise).= / - / 0 zooms the page (persisted), something a bare WKWebView does not offer.Deliberately not in v0.1: tray, OS notifications, file panel, in-app updater, control channel. The architecture (control pipe over stdin/stdout, dshdctl: protocol) is documented in the blueprint and can grow later.
dsh web (your existing web profile)
└─ dsh-desktop-kit (this plugin, inject: [webServer, connection])
└─ connection.authenticatedUrl(clean URL)
└─ spawns dsh-desktop-kit <authenticated-url> <title>
└─ native WKWebView window on http://127.0.0.1:<port>
window closed → exit 0 → plugin shuts the harness down
The process token is used only to establish the persistent signed browser cookie. Logs keep the clean
loopback URL so the credential is not copied into terminal output. The plugin resolves the shell binary
in order: config.bin / DSH_DESKTOP_KIT_BIN → $DSH_HOME/bin/dsh-desktop-kit → PATH → ~/.local/bin/dsh-desktop-kit.
Requires the dsh CLI and macOS (other platforms are untested). Version 0.2.6
supports DSH 0.1.2-rc.1 and later compatible 0.1.x releases, including the
new launch-token authentication flow.
# 1. the plugin
dsh plugin --profile web add dsh-desktop-kit # dsh-market
# or from the latest prebuilt GitHub Release tarball:
dsh plugin --profile web add https://github.com/MDR-EX1000/dsh-desktop-kit/releases/latest/download/dsh-desktop-kit.tgz
# or from a checkout / GitHub source:
dsh plugin --profile web add /path/to/dsh-desktop-kit
# 2. restart dsh web — the release package installs the shell and DSH.app,
# then opens the native window with it
The macOS arm64 release package includes the native shell, native launcher, and app/ assets. The
GitHub source repository also tracks the compiled plugin lib/, the arm64 bin/dsh-desktop-kit and
bin/dsh-launcher, and the app assets, so a dsh-market GitHub-source install does not need a local TypeScript or Rust build on
Apple Silicon. Release packages use the stable filename dsh-desktop-kit.tgz across versions, so
the releases/latest/download URL remains valid after upgrades. On the first dsh web start it
installs the native shell and launcher to ~/.dsh/bin
and creates ~/Applications/DSH.app. Signed executables are replaced atomically so macOS does not
reuse stale code-signature state after a local upgrade, and the completed app bundle is ad-hoc signed
after its resources are assembled so strict bundle verification succeeds. A source checkout still requires cargo build --release
only when rebuilding the native shell; app/install.sh compiles the small native launcher with
clang when a prebuilt bin/dsh-launcher is not present.
If the dsh-market catalog omits the tarball field, dsh-market falls back to
github:MDR-EX1000/dsh-desktop-kit. The installer then uses the repository's current
default-branch commit instead of the latest formal Release; it does not rebuild this plugin during
installation. The committed lib/, bin/dsh-desktop-kit, bin/dsh-launcher, and app/ files are the installable
runtime assets and must remain in Git.
When changing the TypeScript plugin or the native shell, regenerate and commit the corresponding artifacts before users install from GitHub:
pnpm build # refreshes lib/
cd shell && cargo build --release # refreshes the native binary when shell code changed
# copy target/release/dsh-desktop-kit to bin/dsh-desktop-kit
# build/copy app/dsh-launcher.c to bin/dsh-launcher when the native launcher changes
The bundled binary is currently macOS arm64. A GitHub-source install does not cross-compile it for Intel Macs, Linux, or Windows; unsupported platforms keep the browser fallback described above. Choose a Release tarball when you need the exact tested Release contents, and choose the GitHub source target only when following the default branch is intentional.
To uninstall: dsh plugin --profile web remove dsh-desktop-kit, delete
~/.dsh/bin/dsh-desktop-kit, and remove ~/Applications/DSH.app if it was installed.
app/install.sh # builds ~/Applications/DSH.app (native launcher; idempotent)
The bundle's CFBundleExecutable is a native Mach-O launcher, not a shell script. It invokes the
resource script without attaching a TTY, so macOS does not start Terminal.app. The bundle is still
a thin launcher, not a second harness: if 127.0.0.1:3080 already answers
(e.g. a terminal-started dsh web), the icon just opens a window on that instance;
otherwise it boots dsh web --no-open itself. The server still starts normally, but the
desktop entry does not open a duplicate browser client. Starting a second dsh web would
die on EADDRINUSE — earlier hand-rolled wrappers did exactly that when an instance was
already up, which is why the launcher lives in this repo now. An HTTP 401 response counts as
"already running" because DSH 0.1.2 deliberately protects its unauthenticated root URL.
# plugin half (TypeScript)
pnpm install
pnpm build # tsc → lib/
pnpm test # vitest — spawn/exit/resolution logic, all fakes
pnpm typecheck
# shell half (Rust / Tauri v2)
cd shell
cargo build --release # binary at target/release/dsh-desktop-kit
Install the built plugin into your harness for a live run:
dsh plugin --profile web remove dsh-desktop-kit 2>/dev/null
dsh plugin --profile web add /path/to/dsh-desktop-kit
cp shell/target/release/dsh-desktop-kit ~/.dsh/bin/
# restart dsh web
Plugin config keys (defaults shown):
| Key | Default | Meaning |
|---|---|---|
bin | '' | Explicit shell binary path; empty resolves $DSH_HOME/bin → PATH → ~/.local/bin. Also settable via DSH_DESKTOP_KIT_BIN. |
title | 'DSH' | Window title (argv[2] to the shell). |
Shell argv: dsh-desktop-kit [url] [title] — the plugin supplies an authenticated URL; standalone defaults remain http://127.0.0.1:3080 and DSH.
--selftest runs a scriptable native-fullscreen enter/exit check (exit 0 on pass);
DSH_KIT_NO_SINGLE_INSTANCE=1 runs a side-by-side instance (selftest, dev).
dsh web after reinstalling.DSH.app launcher to a server that
was started without Desktop Kit: the launcher has no access to that server process's launch token.
Once Desktop Kit has established the signed cookie for its WebKit data store, later attaches work.MIT