mirror of https://github.com/anywhere-labs/dsh-desktop.git synced 2026-09-28 05:03:17 +08:00

Files

T

zp-home 894e5d667b feat(desktop): inherit the system proxy for Node-side egress (#1087 )

* feat(desktop): inherit the system proxy for Node-side egress

* fix(desktop): send the proxy overlay from the isolated Host boot fixture

* test(desktop): give the child-process logger mocks the new info method

master added desktop-logger.spec.ts cases that build a DesktopLogger mock
with only error/errorCause; this branch adds info() to the interface, so
the merged tree failed typecheck (TS2345). Stable and beta kept identical.

* test(desktop): send the proxy overlay from the agent-error-logging Host boot

master added agent-error-logging.host.spec.ts, which boots a real isolated
Host without desktopProxyOverlay; the Host now installs its outbound
policy at boot and read all_proxy from undefined. Same fix as the
host-process-integration fixture, in stable and beta.

2026-09-23 12:10:01 +08:00

6.7 KiB

Raw Permalink Blame History

DSH Desktop FAQ

中文

This page answers common questions about installation, supported platforms, the bundled runtime, and plugins in the current stable release. The latest GitHub Release and user guide define the shipped product scope.

What is DSH Desktop?

DSH Desktop is an open-source DeepSeek Harness desktop client for Windows and macOS. It packages the official Harness local Web UI, Host service, and plugin system into a native desktop application with a window, system tray, terminal, updates, and profile management.

Is this an official DeepSeek product?

No. DSH Desktop is an independent, community-maintained open-source project. It is not affiliated with or endorsed by DeepSeek. The name only describes its technical relationship with the official DeepSeek Harness.

Which operating systems are supported?

Current release installers support Windows x64 and universal macOS (Intel and Apple Silicon). Linux x64 AppImage and deb artifacts are built by CI but have not shipped with any published release yet; until you see Linux artifacts in the release notes, cross-platform compatibility code in the source tree does not imply that an installer has been released for that platform. Linux arm64 artifacts are not offered.

Do I need to install Node.js, pnpm, or DSH?

No. The installer includes Electron, Node.js, pnpm, and pinned DSH dependencies. Ordinary users can install and launch directly, and Desktop does not modify the global system PATH or user shell configuration.

Does the first launch download a runtime?

No separate Node.js or Harness core download is required. The installer is larger because it contains the runtime and pinned dependencies, trading download size for a more deterministic first launch and dependency set. Cloud models, update checks, and new-version downloads still require network access.

Does DSH Desktop modify official Harness?

No. The repository pins an unmodified official Harness checkout. Compatibility mode runs the upstream default Web client below an independent overlay frame. Extended and enhanced modes each install their own Desktop-owned root registration through the plugin/profile composition boundary while retaining the official slot occupants. None of these modes edits upstream source.

Is data stored locally?

The Desktop Host, profiles, and DSH home live on the local machine. Whether content is sent to an external service depends on the model or tool providers the user configures; requests to cloud models still go to those providers.

Can I install DSH plugins?

Yes. DSH Desktop uses the official Harness plugin system. Open DSH Terminal from the tray and run dsh plugin add, dsh plugin remove, or dsh plugin update. These commands default to the active profile, and Desktop must be restarted after plugin changes.

Does the Desktop profile automatically sync with an existing web profile?

No plugins are copied automatically. Each profile has its own bundle and dependency composition. After switching profiles, default plugin commands target the active profile; --profile <name> can always select one explicitly.

How are updates installed?

Packaged applications check for stable releases in the background but never install silently. A newer version requires confirmation. Before downloading, a native save dialog lets you choose the installer's directory and filename; cancelling it does not start a download. macOS downloads and opens a DMG; Windows downloads and starts an NSIS installer. After the upgrade and next launch, the app asks whether to delete or keep the installer. Network and download failures leave the current installation intact.

Does the app use my system proxy?

Yes. At startup the app reads the operating system's proxy configuration — Windows Internet options, macOS network settings, Linux desktop settings, including automatic configuration scripts (PAC/WPAD) — and applies it to everything it sends: model conversations, web fetches, web search, MCP servers, plugin installs, and commands the app starts in its terminal. Turning on the "system proxy" switch in a client such as Clash or v2rayN is enough; nothing needs to be entered in the app.

A few rules worth knowing:

A proxy you set yourself wins. If HTTPS_PROXY, HTTP_PROXY, or ALL_PROXY is set before launch, the app uses that one and ignores the system configuration. NO_PROXY is honored the same way.
Restart the app after changing the proxy. The configuration is read once, at startup. After toggling the system proxy in your client, or switching to a node that changes the port, quit the app and open it again.
A SOCKS-only configuration cannot be used. The app's HTTP egress accepts only http:// and https:// proxies. If the system proxy is configured for SOCKS alone, enable the HTTP port or the mixed port in your proxy client (Clash's "mixed port" serves both), then turn the system proxy on. The application window itself and the update check keep working either way; only the features listed above connect directly.
Local addresses never go through the proxy. localhost, 127.0.0.1, and this machine's own LAN addresses bypass it, so a locally running server or a LAN address is never blocked by the proxy.
Known limitation: on macOS and Linux, launching from the Dock or Finder does not pick up proxy variables written only in ~/.zshrc or ~/.bashrc. This is deliberate — a proxy address can carry a username and password, and the app does not inherit that class of variable from shell configuration. Use the system proxy settings instead, or start the app from a terminal.
How to confirm it worked. Every start writes one outbound proxy = ... line to the log, for example outbound proxy = http://127.0.0.1:7890 (source: system, no_proxy: ...). A source of system means the system configuration was used, environment means a variable you set was used, and none means the app is connecting directly. The log lives in the logs folder of the application data directory, and "Export diagnostics" packages it up. Please include that line when reporting a network problem.

Where can I download the app or report a problem?

Download from the project download page or the latest GitHub Release. Check the troubleshooting section first. If the problem remains, open a GitHub Issue with the operating system, app version, reproduction steps, and error details.

6.7 KiB Raw Permalink Blame History