# deepseek-harness-remote: A Plugin-Based Bridge for Operating DeepSeek Harness from Any Device > This TypeScript plugin extends DeepSeek Harness with a bidirectional, end-to-end encrypted channel so desktop, web, and Android clients can resume sessions and control a remote Host. It is a practical solution for engineers who want to keep Harness running on one machine while interacting from others, but it carries transport-generation constraints and a hosted relay dependency. **liguobao/deepseek-harness-remote** — A multi-device remote access solution built on the DeepSeek Harness plugin system, enabling desktop and Android clients to securely connect to and operate a remote Harness. - Repository: https://github.com/liguobao/deepseek-harness-remote - Website: https://dsh.r2049.cn/ - Stars: 518 · Forks: 53 - Language: TypeScript - License: not declared - Published: 2026-08-21 · Updated: 2026-08-21 · Language: en - Canonical page: https://hysenlabs.com/projects/liguobao-deepseek-harness-remote ## What This Plugin Solves and Who It Is For DeepSeek Harness is a desktop-centric environment where sessions, tools, and workspaces live on one computer. If you step away from that machine, you lose the ability to continue a conversation or answer a permission request. deepseek-harness-remote addresses that by letting you connect to the same Harness instance from a phone, another computer, or a browser. The README describes it as 'simply another window into that environment,' which is accurate: the Harness Host keeps running with its original workspaces and tools, and the remote client becomes a view into that existing setup. This is for engineers who work across devices, perhaps starting a long-running task on a desktop and wanting to check progress or inject new instructions from a phone. It is also for teams that need to answer permission prompts from a remote location without standing up a full remote-desktop solution. The project is an independent community effort, not an official DeepSeek product, so adopters should treat it as a community-maintained bridge rather than a vendor-supported feature. ## How It Works: The Channel and the API Switch The architecture is a three-layer chain. On one end you have the client, which can be DSH Desktop, Remote Web, or the Android app. On the other end is the Remote Plugin running on the Host. Between them is an authenticated, end-to-end encrypted channel. The documentation states that the Host does not need a public listening port; the channel is bidirectional, so the client can reach the Host even when the Host is behind NAT or a firewall. When a client selects an online Host and opens a workspace, the plugin switches the client to the Host's native Harness API. That means the original workspace, tools, and permission flow remain on the Host computer; the client is not running a separate conversation UI. The plugin also exposes remote configuration of every settings namespace currently registered by the Host through the official Harness settings API. Credential values remain write-only, and Host-local document or open actions are never exposed. This design keeps the remote surface narrow, which is a deliberate security choice. The relay service only sees ciphertext; it does not store session plaintext or device private keys. ## Getting It Running: Two Installation Paths There are two ways to install. Path A is to use DSH Desktop, a separate companion application for Windows, macOS, or Linux. The README says Remote is included and enabled by default in DSH Desktop, so no extra plugin installation is needed. Path B is for an existing DSH installation. You install the exact npm version for the web profile with this command: 'dsh plugin --profile web add ds-harness-remote@0.4.1'. After that, restart Harness. The quick start flow is straightforward: open Remote from the Harness sidebar, sign in with a GitHub or Zhihu QR code, or use an account and password. New password accounts can register through Remote Web, but the site shows current invitation requirements, which suggests registration is not open to everyone. Then you enable remote control for the current computer, making it a Host. On another device, you sign in to the same account, select the online Host, and choose an existing workspace or browse remote directories. The public service currently uses a hosted Remote relay; a self-hosted relay option is not available yet. That is a significant operational constraint for organizations that want to keep all traffic within their own infrastructure. ## Compatibility Boundaries: The Breaking Change in 0.4.1 The release notes for 0.4.1 include a breaking change notice that is easy to miss but critical for adoption. The plugin removes the earlier experimental Remote business RPC surface, including sessions.*, session.*, permissions.respond, and sync.from. Harness session traffic now only uses the official rc.2 ApiProxy or the alpha.1 Typert Remote Gateway. The plugin does not provide an adapter or wire-format translation for the old RPC surface. This means if you have a Host running an older plugin version that relied on that experimental surface, upgrading to 0.4.1 will break that connection. More importantly, 0.4.1 supports two different Harness versions: dsh-v0.1.1-rc.2 through the legacy ApiProxy and dsh-v0.1.2-alpha.1 through the official Typert Remote Gateway. A 0.4.1 Client running rc.2 remains compatible with older rc.2 Hosts through a legacy capability fallback, but there is no cross-generation compatibility. An alpha.1 Client cannot open an rc.2 Host, and an rc.2 Client cannot open an alpha.1 Host. Mixed connections are rejected before switching the native UI or mutating a Workspace. This is a hard compatibility wall. If your team has both rc.2 and alpha.1 machines, you cannot use this plugin to bridge them. ## Security Model: What Is Exposed and What Is Not The security section of the README is detailed and worth reading carefully. Session traffic is end-to-end encrypted, and the relay service does not store plaintext or device private keys. Connection authorization requires two things: server membership and the Host's locally pinned peer identity. That dual check means an attacker who gains a valid account still needs the Host to accept the peer identity. The plugin does not expose a direct shell, PTY, general tool RPC, or remote desktop. That is a strong boundary against remote code execution outside Harness's normal permission controls. However, the README notes that Harness tools may still modify files or run commands on the Host under Harness's normal permission controls. So the risk is not eliminated, it is delegated to Harness's own permission system. The workspace picker only lists folders and returns bounded, read-only directory metadata. The optional File Viewer is limited to authenticated, encrypted range reads and enforces provider root and locator authorization. Remote file preview cannot write, delete, upload, execute, or open a path in an external application. Removing a device revokes its credentials, membership, and active connections. This is a well-considered security posture, but it relies on the Host's permission configuration being correct. If Harness tools are configured with broad permissions, the remote client inherits that breadth. ## A Genuine Limitation: The Hosted Relay Dependency The most concrete limitation is that the public service uses a hosted Remote relay, and a self-hosted relay option is not available yet. That means all traffic between your client and Host passes through the project's relay servers, even though it is encrypted. For a community project, this is a trust question. You are relying on the relay operator to not log metadata or to not be compromised, even though they cannot read session content. For organizations with strict data-residency requirements, that is a dealbreaker. The README does not provide a timeline for self-hosting, so you must assume this dependency is permanent for now. Another limitation is the lack of a direct shell or remote desktop. If your use case requires full control of the Host's desktop or a terminal outside Harness, this plugin is the wrong tool. It is specifically a Harness session bridge, not a general remote access tool. The compatibility wall between rc.2 and alpha.1 also limits flexibility. You cannot mix versions across devices, which is a practical constraint for teams that upgrade gradually. ## A Real Alternative: Direct Harness Access vs. This Bridge The obvious alternative is to run DeepSeek Harness directly on the device you are using, with no remote layer at all. That is the approach Harness itself is designed for: a local desktop environment where sessions and tools live on the same machine. The difference is that direct access gives you full performance and no network dependency, but it forces you to carry your work environment with you or set it up on each machine. deepseek-harness-remote trades that portability for a persistent Host. Another alternative is a general remote desktop tool like VNC or RDP, which gives you the entire screen but exposes a much larger attack surface and requires a public port or a VPN. The plugin's approach is narrower: it exposes only the Harness API, not the operating system. So if you need to operate Harness specifically, this plugin is more secure than a full remote desktop. But if you need to operate other applications on the Host, a remote desktop is the only way. The choice depends on whether the Host is dedicated to Harness or serves multiple purposes. ## Maintenance and Upgrade Cost The project has a clear release cadence, with versions 0.3.32, 0.3.36, and 0.4.1 pushed within a few days in late August 2026. That frequency suggests active development, but it also means you should expect frequent updates. The breaking change in 0.4.1 is a warning: upgrading the plugin can break existing connections if your Harness version does not match. The README does not describe an upgrade path or migration tooling. You must manually check the compatibility matrix and ensure both endpoints use the same transport generation. The license is listed as unknown, which is a significant gap. You cannot legally adopt this plugin without knowing its license terms. The README acknowledges it is an independent community project and not an official DeepSeek product, but it does not specify a license identifier. Before using it in a production environment, you should contact the author or check the repository for a LICENSE file. The absence of a license means you have no legal rights to use, modify, or redistribute the code, which is a blocker for many organizations. This is a concrete maintenance cost that adopters must resolve before deployment. ## Conclusion Adopt deepseek-harness-remote if you run DeepSeek Harness on a dedicated work machine and need to resume sessions, answer permission prompts, or open workspaces from a phone or second computer without exposing a public port. Avoid it if you require a self-hosted relay (not yet available) or if you must mix rc.2 and alpha.1 clients and hosts, since 0.4.x rejects such mixed connections. Before deploying, verify that your Harness version matches the plugin's supported transports (dsh-v0.1.1-rc.2 via ApiProxy or dsh-v0.1.2-alpha.1 via Typert Remote Gateway), and confirm that both endpoints use the same generation. Also check the invitation requirements on Remote Web before registering new accounts, as they are not fixed. ## FAQ ### How do I install the deepseek-harness-remote plugin? Through the Harness plugin manager for the web profile, with the version pinned: `dsh plugin --profile web add -w ds-harness-remote@0.4.27`, then restart Harness. The `-w` flag targets the profile's own workspace root and is required on pnpm below 11, which otherwise fails with `ERR_PNPM_ADDING_TO_ROOT`. Do not install the package with npm directly. ### Does the deepseek-harness-remote Host need a public port? No. The Host does not need a public listening port, and the connection is a bidirectional end-to-end encrypted channel. The public service uses a hosted relay, and a self-hosted single-account server is available for anyone who wants to run the relay themselves. ### Is remote terminal access on by default in deepseek-harness-remote? Yes, along with control of the current computer. Both start enabled on the Host, and terminal access can be turned off in the detailed Remote settings. The Android terminal panel only creates a new terminal when you tap plus, and it never replays input after a disconnect. ### What do I need to run my own relay for deepseek-harness-remote? Run the optional single-account server in the apps directory, set `DSH_SERVER_ACCOUNT` and `DSH_SERVER_PASSWORD`, then point both the Host and the Client at your server URL and sign in with the same account. Its Web page offers login and device status only, and device credentials survive restarts. ### Which DeepSeek Harness versions does deepseek-harness-remote support? Sending instructions, changing direction and image prompts work from dsh-v0.1.1-rc.2 through dsh-v0.2.0-rc.2. The Files and Terminal tools need the native APIs in DSH 0.1.6-alpha.2 or later plus an updated Remote Host plugin, and an unsupported Host shows an actionable error rather than fabricated permission options. ## Sources - [Official documentation](https://dsh.r2049.cn/) - [Official README](https://github.com/liguobao/deepseek-harness-remote#readme) - [Project repository](https://github.com/liguobao/deepseek-harness-remote) - [Release notes](https://github.com/liguobao/deepseek-harness-remote/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/liguobao-deepseek-harness-remote