dsh-status-bar

dsh-status-bar

DSH bundle for DSH Status Bar — a floating glass status bar for DeepSeek Harness. The npm name and the bundle row id are dsh-status-bar-plugin. npm already hosts an unrelated dsh-statusbar, so the registry rejects the shorter name as too similar.

What it does

The plugin mounts one host row in DSH. At boot it waits for the local web server, asks the connection service for the authenticated host URL (connection.authenticatedUrl(origin)), and starts the desktop app with that link:

electron <app dir> --dsh-link=<authenticated url> --launcher-pid=<host pid>

The companion connects with that link on launch, so nothing has to be pasted. The link travels only in the process arguments and is never logged — the plugin prints [dsh-status-bar] Glass desktop companion launched (authenticated link redacted). The app rejects non-loopback links, credentials, hashes and sub-paths before it touches the network. --launcher-pid makes the companion exit when the DSH process it belongs to disappears; disposing the plugin kills the spawned tree.

If the companion is already running, the second launch hits its single-instance lock: the existing window is focused and re-connected with the new link.

Reopening a hidden or closed companion

Hiding the window keeps the process alive; Ctrl+Shift+G toggles it back. After the user quits the companion, the plugin registers the DSH slash command /status-bar. Invoking it in any session asks DSH for a fresh authenticated link and either shows the existing instance through the single-instance hand-off or starts a new one. The command is registered even when autoLaunch: false, so a manually disabled companion can still be opened without restarting DSH. It never stores or replays an old token.

Install

From npm, from the plugin market (once listed), or straight from the release tarball:

# npm: ~870 kB, fetches the 155 MB runtime once on first launch
dsh plugin --profile web add dsh-status-bar-plugin

# release tarball: 155 MB, self-contained, nothing downloaded later
dsh plugin --profile web add https://github.com/wfz2006/dsh-status-bar/releases/latest/download/dsh-status-bar.tgz

Both end up as the same companion: the built desktop app plus an Electron runtime. The tarball carries them; the npm package reads the download URL from its own manifest (dsh.statusBar.runtime), fetches that tarball the first time DSH starts it, and unpacks it into a per-version cache: %LOCALAPPDATA%\dsh-status-bar\runtime- on Windows, ~/.cache/dsh-status-bar/runtime- elsewhere. Later launches reuse that cache, so the download happens once per version.

On Windows, a small native preparation window shows download progress before Electron is available. A failed download shows Retry and Try later; retry continues without restarting DSH. Cancel stops the preparation and keeps the verifiable partial for the next launch. A valid cache opens the companion directly, without flashing the preparation window.

The downloader prefers system curl (and falls back to Node if unavailable), checks stalled connections, and makes up to three attempts. Partial files live beside the cache as runtime-.tgz.part; Range resume requires an ETag or Last-Modified validator. If the server ignores Range or no validator exists, the file is downloaded afresh rather than concatenated incorrectly. Corrupt archives are discarded; extracted content must match the plugin version before it replaces a cache. A per-version lock prevents concurrent hosts from writing the same partial/cache. Plugin disposal aborts preparation and prevents late launch.

The default GitHub URL is pinned to releases/download/v/..., even for older manifests advertising latest. An explicit download URL override is respected; its archive must still match the installed plugin version. No authenticated DSH link is requested until the runtime is ready, and progress files contain no Host token or Cookie. Non-Windows environments retain log output; the native progress UI is Windows-only.

Renamed in 0.2.3. The old package id was dsh-glass-plugin; it still resolves

to the same app, but new installs should use dsh-status-bar-plugin.

From a checkout (development)

The desktop profile can link the package instead of installing it:

// <profile>/package.json
"dependencies": { "dsh-status-bar-plugin": "link:D:/codexwork/dsh/dsh-glass-spec/packages/dsh-status-bar" },
"dsh": { "profile": { "bundles": [/* ... */ "dsh-status-bar-plugin"] } }

In a checkout the plugin uses apps/desktop/out as the app directory and the workspace electron package, so run pnpm build first. Point a junction or symlink at node_modules/dsh-status-bar-plugin if pnpm did not run, then restart DSH.

Configuration

The bundle patch sets autoLaunch: true. To keep the plugin installed but stop it from launching the companion at boot, override the row config in the profile patch; /status-bar remains available for manual launches:

- id: dsh-status-bar-plugin
  config:
    autoLaunch: false

Other overrides, all optional:

key · meaning :-- · :-- appDir · directory holding out/main/index.js electronBinary · path to an Electron executable runtimeDir · where the downloaded runtime is cached downloadUrl · override the runtime tarball URL autoReload · relaunch the companion when the desktop bundle changes (default true) showStartupUI · show native Windows preparation/error feedback (default true); disable only for intentionally headless use

The same settings are available through the environment: DSH_STATUS_BAR_APP, DSH_STATUS_BAR_ELECTRON, DSH_STATUS_BAR_RUNTIME, DSH_STATUS_BAR_RUNTIME_URL. The pre-0.2.3 names (DSH_GLASS_*) still work as fallbacks.

Requirements

• Windows 11 x64 (the glass refraction reads the screen behind the window).
• The desktop app is a separate Electron process; it needs a GPU-backed Electron

runtime, which the release tarball provides.

License

MIT. The bundled Electron runtime keeps its own license files (electron/dist/LICENSE, LICENSES.chromium.html).

Development verification

From the repository root, run pnpm test and pnpm test:plugin-startup after pnpm build. The latter uses a temporary thin-plugin install, local HTTP/Host, native WPF feedback and the actual workspace Electron through the documented electronBinary override. It does not reinstall or enable the production plugin. See first-run recovery for evidence and limits.