Abstract

This guide provides a comprehensive walkthrough for the DeepSeek Harness community plugin dsh-zen-remote (v2.2.2). It covers mobile PWA web access, desktop endpoint pairing, HTTPS gateway configuration, and notification activation workflows. A critical prerequisite is completing at least one dialogue validation on the host machine. Users will configure HTTPS entry points with reverse proxies such as Caddy, assign device roles including web endpoint and client terminal, and generate pairing codes to connect remote devices. The tasks always run locally on the host, and mobile and desktop clients see different scopes of conversation data. Ordinary conversation endings do not trigger push notifications by default. This tutorial walks you through the complete setup sequence to avoid common pitfalls such as false "already connected" errors.

1. Introduction to dsh-zen-remote

Maintained by KyoMio, dsh-zen-remote is a community-contributed plugin for DeepSeek Harness. As of October 2026, this plugin enables mobile users to view and interact with Harness conversations via a Progressive Web App (PWA). It also supports sharing selected conversations to separate desktop endpoints. This document is built around the official v2.2.2 release notes and installation documentation.

It is important to clarify that dsh-zen-remote is a community plugin, not an official DeepSeek product. According to npm release metadata collected on October 15, 2026, the latest tag points to version 2.2.2, published on October 14.

The plugin uses role switching on the same host machine. The PC running active Harness sessions takes the host service role. Additional desktop clients or mobile web browsers operate as client endpoints. Desktop clients only require pairing setup; they do not need to run a separate instance of Harness.

The core value of this plugin is straightforward: you can leave your primary computer running Harness and continue to check conversation progress, submit new messages, approve authorization requests, or send follow-up prompts from mobile or secondary desktop devices. All inference and task execution stays on the host machine, so the host must remain powered on, connected to the network, and running Harness for remote access to function.

2. Pre-Install Verification and Model Configuration

Before installing the plugin, confirm that your host machine can run normal LLM conversations. Remote access builds on existing working Harness sessions, so resolving basic chat functionality first helps separate model configuration failures from remote connectivity issues.

When you need to connect model endpoints, you can follow the Treerouter DeepSeek Harness integration guide. Navigate to Settings → Models → Custom Definition and fill in your API address and model identifier. Retrieve your API key and model ID from your Treerouter console. All model connection logic runs on the host machine.

You can install the plugin either from the graphical interface or via the command line. For desktop or web UI: open the Harness App, go to Plugins → Add Plugin, search for dsh-zen-remote, install it, click enable, then restart the web or desktop service.

For environments that already use the dsh CLI tool, run the maintainer’s installation command:

dsh plugin --profile web add dsh-zen-remote

After installation, restart the service with dsh web. The --profile web parameter is mandatory and cannot be replaced. Desktop application profiles are managed through the desktop UI, and you cannot reuse the --profile desktop flag for web plugin installation.

3. Mobile PWA Web Access: Configure HTTPS Before Pairing Codes

Public mobile web access requires a valid HTTPS entry point, which forwards traffic to the plugin gateway. Installing the plugin will not automatically provision a public domain or SSL certificate.

According to maintainer documentation published in October 2026, the gateway defaults to listening on 127.0.0.1:3088. It can auto-detect the actual Harness web UI port, so users usually do not need to manually define targetPort. Avoid hardcoding a fixed host port across all desktop deployments.

The following example uses Caddy as a reverse proxy on a machine with a resolved domain and HTTPS certificate. Replace dsh.example.com with your actual domain:

dsh.example.com {
  reverse_proxy 127.0.0.1:3088
}

Caddy forwards request headers to distinguish local traffic from public internet requests. If port 3088 is occupied, the plugin may select an alternate port. Always check the plugin status page first and update your reverse proxy target to match the actual gateway listening port.

Pairing Procedure

Follow this ordered workflow for device pairing:

  1. On your mobile device, disable Wi-Fi and load https://<your-domain>/lan-gate/admin over cellular data. The page should return a 403 response.
  2. If you see the management page, fix your reverse proxy X-Forwarded-* header forwarding rules before proceeding.
  3. Navigate to the plugin settings on your host machine, select the Web Application endpoint role, and generate a pairing code.
  4. Open your HTTPS domain on the mobile browser, input the pairing code on the pairing page, then add the web app to your home screen via browser menu.

The pairing code is an 8-character string, valid for 10 minutes and single-use only. Each code binds to a specific device role. Mobile and desktop pairing codes cannot be interchanged. Code generation, device revocation, and all management actions are performed locally on the host machine.

4. Secondary Desktop Endpoint: Enable Remote Session Access After Pairing

Desktop client terminals only display conversations that the host has explicitly shared for remote access. A successful pairing status with an empty sidebar conversation list does not automatically indicate a connection failure.

Install the plugin on both computers. On your host machine, generate a pairing code for the desktop application endpoint. On the second desktop, switch the plugin role to client mode, save settings, and fill in the host HTTPS address and pairing code. Public network connections use HTTPS; local LAN connections can use HTTP, but verify LAN network reachability first.

After pairing, open the ... menu inside an active host conversation and select Enable Remote Access. The desktop client sidebar will display grouped sessions labeled with your host device name and workspace name. You can view conversation history, send messages, approve requests and use the terminal from this secondary desktop.

Mobile browser clients have access to all host conversations, while desktop client terminals have limited visibility restricted to shared conversations only. This sharing switch only controls conversation data access. The desktop remote terminal acts with the host machine’s identity, with file read capabilities extending beyond conversation logs. For this reason, only trust devices you fully control as desktop remote endpoints.

Per October 2026 plugin documentation, shared inactive sessions automatically close after 48 hours of idle time. You can adjust this value using the idleHours parameter. Active sessions, pending authorization requests, and waiting LLM responses will not be cleared. Simply opening the page does not reset the idle timer.

5. Permission Differences: Mobile Web vs Desktop Client

There is a clear distinction in conversation scope for each connected device type:

  • Mobile / Web Browser (Web Endpoint): Full visibility of all conversations stored on the host machine. After pairing, users can view every session unless individual conversations are restricted.
  • Host Machine (Host Role): Where all tasks execute. Host users manually toggle sharing for each individual conversation.
  • Secondary Desktop (Desktop Client): Can only view conversations marked as shared by the host. Unshared conversations remain invisible.

The documentation emphasizes an important security note: the sharing toggle only limits conversation data visibility. A desktop remote client retains operational capabilities equivalent to the host, so treat desktop endpoints as trusted devices. Mobile web PWA clients have narrower system-level permissions compared to desktop clients.

6. Notification Configuration: Troubleshoot Missing Push Alerts

By default, dsh-zen-remote sends push notifications when waiting for user authorization or user input. Standard conversation completions do not trigger push alerts automatically. To receive end-of-task reminders, toggle pushTurnEnd in the host plugin settings.

Notification bodies can optionally include a summary of the final response using the pushSummary flag. You can enable this setting based on your device lock-screen display preferences. Always test push delivery via the settings test notification function first before validating real authorization workflows, to simplify debugging.

iOS and iPadOS impose additional requirements for PWA Web Push notifications. According to WebKit documentation, iOS / iPadOS 16.4+ support Web App Push for PWAs saved to the home screen. Permission prompts must originate inside the added web application.

Additionally, modify the vapidSubject field inside host plugin settings. Replace the default placeholder value with a valid mailto: email address or HTTPS contact URL. Maintainer documentation confirms that the default placeholder VAPID subject will cause Apple servers to reject push delivery entirely.

7. Troubleshooting Remote Connection Failures

Debug remote connectivity in sequence: Host → Gateway → Pairing → Conversation → Notification. Validate each layer before investigating the next.

  • Host chat works, mobile page fails to load: Verify HTTPS entry, reverse proxy target, and listening port. The gateway binds to localhost by default. LAN-only deployments require extra listening address adjustments.
  • Pairing code fails validation: Confirm the correct device role, expiry time, and whether the code has already been consumed. Regenerate a fresh pairing code on the host for the target device role.
  • Paired successfully but no conversation list: First verify that remote sharing has been toggled on for individual host conversations. Check that both host and client run matching plugin versions; maintainers require identical dsh-zen-remote versions on both ends.
  • Plugin panel inaccessible after normal web load: Check if the conversation is using remote terminal features. Do not assume all third-party plugin UIs can be accessed remotely just because web access works.

8. Deployment Best Practices

The plugin’s core architecture keeps computation local on the host. This reduces inference cost and keeps raw model data within your host machine. When scaling multi-model access across many endpoints, teams often leverage an API gateway to centralize routing and access control. Treerouter handles unified authentication, rate limiting and logging for multiple LLM backends, simplifying integration when running Harness across distributed remote clients.

When planning remote access workflows, separate concerns clearly: pairing and permission management live inside dsh-zen-remote, while API key management and model endpoint routing are managed outside Harness via your gateway. This separation reduces the blast radius of configuration changes and keeps remote client access stable.

Version alignment is critical for multi-device deployments. Always match the plugin version on host and desktop clients. Mismatched versions are the most common source of silent pairing or conversation sync issues. Keep host machine time synchronized; pairing codes are time-bound and will fail if there is significant clock drift between host and client devices.

9. Conclusion

The dsh-zen-remote community plugin for DeepSeek Harness extends your local AI workspace beyond your primary PC. With proper HTTPS reverse proxy setup, role-based pairing, and notification tuning, you can monitor ongoing tasks, approve requests, and review outputs from mobile PWA or secondary desktop clients.

This architecture preserves local execution of all LLM workloads, while selectively sharing conversation sessions to trusted remote endpoints. The permission model differentiates mobile web viewers from powerful desktop remote terminals, giving granular control over what each remote device can access. Following the ordered pairing and debugging workflow prevents many common setup mistakes.

For teams managing multiple model endpoints and API credentials alongside Harness deployments, centralized API gateway tooling simplifies cross-service governance. Treerouter provides a unified layer to manage model backend access, removing repetitive configuration work when connecting remote clients to hosted or local LLM services.

Learn more：https://treerouter.com