dsh-desktop
Discovered★ 3基于Tauri的简易dsh桌面端套壳 | A simple Tauri-based desktop wrapper for dsh
dsh-desktop
English | 中文
A Tauri 2 desktop shell for the DeepSeek Harness Web surface. The dsh plugin
@aqian0/dsh-desktop-plugin launches dsh-desktop --attach <url> with the Web
runtime's authenticated loopback URL and opens the Web app in a single desktop
window. The runtime remains the parent process; closing the window exits
the profile, and the window never outlives the runtime.
Prerequisites
dshCLI 0.1.2-rc.1 or newer:npm i -g @deepseek-ai/dsh@next- For source installs: Node.js + pnpm, Rust, and the Tauri platform prerequisites.
Installation
Quick install as a dsh plugin
dsh plugin --profile desktop-tauri add @aqian0/dsh-desktop-plugin
dsh --profile desktop-tauri
The plugin package ships per-platform prebuilt shell binaries through
optionalDependencies, so no Rust toolchain is required. Its bundle layer also
pins web-runtime.openBrowser to false, so dsh --profile desktop-tauri opens
only the desktop window and never hands the URL to the system default browser.
Inside the shell, same-origin Web app routes keep navigating in the window,
while links to other origins and mailto:/tel: links are handed to the
system default browser or app. The initial URL carries the process launch token,
which the Web runtime exchanges for its session cookie; the shell keeps
supervising that session for as long as the window lives (see
Session authentication and recovery).
If the profile was newly created and has no Web bundle, set
dsh.profile.bundles in ~/.dsh/profiles/desktop-tauri/package.json to:
["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "@aqian0/dsh-desktop-plugin"]
@deepseek-ai/dsh-web-app resolves from the installed dsh; do not add it from
npm.
Manual install from source
git clone https://github.com/aqian0/dsh-desktop.git
cd dsh-desktop
pnpm install
pnpm shell:build
pnpm plugin:install # adds ./plugin to the desktop profile and configures bundles
DSH_DESKTOP_BIN=src-tauri/target/debug/dsh-desktop dsh --profile desktop-tauri
pnpm plugin:install is idempotent; after pulling changes re-run
pnpm shell:build && pnpm plugin:install.
Build and packaging
pnpm build:no-bundle # release binary
pnpm build # release binary + platform installers
pnpm package:current -- --build # package plugin + current-platform binary for npm
pnpm plugin:smoke # GUI-free lifetime smoke test
Session authentication and recovery
The runtime authenticates the window once. The ?token=... on the URL the
plugin hands the shell is accepted only on GET /, is exchanged for an
authority-bound HttpOnly session cookie (30 days by default, dsh's
cookieMaxAgeDays), and the window then lives on that cookie alone. Only the
shell keeps the launch token, so only the shell can mint a replacement — which
is what the binary's session supervisor does for the whole life of the window:
- a cookie whose expiry enters its last 7 days is re-minted over loopback and installed in the webview's own jar, without touching the page;
- a cookie the runtime stops accepting (every RPC answers
401, which is how a "cannot switch models" surfaces on the desktop) or one missing from the jar makes the shell re-run the token exchange by reopening the authenticated URL, which also replaces a window left on the runtime's401page; - a session that stays broken after three repairs is reported once per backoff window instead of reloading the window forever.
Recovery is driven entirely from the shell, so the runtime needs no
desktop-specific behavior, and the launch token stays valid for as long as the
runtime runs. The --attach value is parsed verbatim: trailing-punctuation
trimming would corrupt a launch token whose base64url form ends in _.
Desktop startup and input focus
macOS, Windows, and Linux share one startup sequence:
- Create the native window hidden, without requesting initial window/WebView focus.
- Wait for Tauri
Readyand the next event-loop drain, then request show once. - Once the window reports visible and not minimized, request native-window focus and embedded-WebView focus once, then retire the startup handler.
On Linux, GTK applies show asynchronously. The handler restores GTK focusability before show and waits for visibility on subsequent event-loop drains rather than issuing a focus request that the still-hidden window would ignore. On macOS this also separates window presentation from AppKit's launch callback; WKWebView may still activate the application during construction.
Startup does not wait for page loading and applies to the startup-error page too. A close/destroy event, an observed minimized state, or a main-window blur event while waiting for visibility cancels pending focus. The shell does not run a focus timer or re-trigger startup on page reloads, app switches, or display changes. Activation remains subject to Windows foreground rules and Linux window-manager/ compositor policy, including Wayland; a successful API call does not guarantee foreground activation.
Rust source changes do not update an installed prebuilt binary. To test locally, run from the project root (macOS/Linux):
pnpm shell:build
DSH_DESKTOP_BIN="$PWD/src-tauri/target/debug/dsh-desktop" dsh --profile desktop-tauri
Windows PowerShell:
pnpm shell:build
$env:DSH_DESKTOP_BIN = Join-Path $PWD "src-tauri/target/debug/dsh-desktop.exe"
dsh --profile desktop-tauri
Run the platform-independent startup state tests with
cargo test --locked --manifest-path src-tauri/Cargo.toml. The package/release
matrices also run these tests on each native build runner before packaging.
Manual regression checks (require each native desktop; unit tests are not enough):
- Repeat cold launches on primary and secondary displays with mixed scaling; cover macOS Spaces, Windows foreground restrictions, and Linux X11/Wayland. When activation is granted, buttons and text input should work immediately, without first clicking another display.
- Switch to another app, reload the page, and minimize or close the window during startup and afterwards; it must not keep reclaiming focus or restoring itself.
- Verify the window still appears with a slow/unavailable Web page and when
launched without
--attach(the startup-error page). - Check single-display startup and both lifetime directions: closing the window exits the profile, and stopping the runtime closes the window.
License
MIT — see LICENSE. The app icon under icons-src/ and
src-tauri/icons/ is derived from the DeepSeek Harness Web favicon and is used
under the same MIT license.
Comments
Loading…
Similar plugins
by RAFOLIE
DeepSeek Harness desktop shell — Tauri v2, tray + native webchat + task-done toasts, single portable exe
★ 22
MIT
TypeScript
Sep 20, 2026
dsh plugin --profile web add dsh-desktop-pluginby WJZ-P
Desktop version of DeepSeek Harness. 由tauri构建的DeepSeek Harness 桌面端,高效简洁。
★ 14
↓ 473.9k/wk
MIT
TypeScript
Aug 19, 2026
dsh plugin --profile web add @deepseek-ai/dsh-baseby boxeryao
DSH-TUI: a lightweight and fast terminal plugin connected directly to the DSH runtime.
★ 9
↓ 112/wk
MIT
TypeScript
Aug 16, 2026
dsh plugin --profile web add dsh-mini-tuiby anywhere-labs
为 DeepSeek Harness (DSH) 插件生态打造的现代化桌面端解决方案。万物皆「插件」,桌面本身也是「插件」。
★ 27.9k
↓ 176/wk
MIT
TypeScript
Sep 20, 2026
dsh plugin --profile web add dsh-plugin-desktopby cilis
Tauri 2 desktop application for Windows that detects (or installs) the global @deepseek-ai/dsh package, launches the DSH Web server and embeds it in its own window, with system tray management, login
★ 2
↓ 432/wk
MIT
Rust
Sep 18, 2026
dsh plugin --profile web add @lenorin/dsh-tauri-launcherby jiangnanquan
DSH web UI 增强插件 + 无边框 Electron 桌面壳
★ 8
MIT
JavaScript
Sep 17, 2026
dsh plugin --profile web add dsh-enhance