Introduction¶

When performing remote development with DSH, a common approach is to first sync or mount the remote directory locally and then point DSH’s working directory at it. The problem with this method is that the workspace is essentially a local mirror; any changes in the real remote directory require manual synchronization. Port forwarding must be set up manually, and remote operations are scattered across separate terminal windows. Consequently, local and remote sessions become disjointed, leading to a mismatch in context.

The dsh-remote-deck introduced below takes a different approach: the plugin connects directly to the SSH target machine within the DSH desktop, registering a remote directory as a regular workspace (workspace stub) for DSH. Subsequently, the agent reads, writes, searches, runs commands, opens terminals, and forwards ports, all via the remote machine, while the interface remains within the same DSH window.

What is it?¶

Remote Deck (package name dsh-remote-deck) is a client plugin for DeepSeek Harness. The repository is at dsh-plugins-cn/dsh-remote-deck on GitHub, and the README title reads “SSH workspaces for DeepSeek Harness — one window, local and remote conversations side by side”. The community directory classifies it under the “Client” category, and as of 2026-11-06, it has 1 GitHub star (based on the directory page and repository page).

It solves the issue of making a directory on a remote Linux/macOS machine appear as a local workspace within DSH. No agent needs to be installed on the remote side; it only requires sshd.

It should be noted that DSH’s philosophy is “everything is a plugin,” and the community directory is an independent site, not DeepSeek’s official app store. Plugins listed on it are not official apps. It is recommended to check the source code yourself before installing.

Core Features¶

The feature list in the README is divided into six sections; here, only the verified content is listed.

• Connection management. Supports connecting to multiple hosts simultaneously, authentication via key or password; can import ~/.ssh/config; returns OS type and latency before connecting, supports auto-connect (default off, switchable in dialog, quick panel, or console), keepalive, and disconnect reconnect backoff. Each host has its own color indicator.
• Workspace. Browse remote directories via breadcrumb paths, with filters and keyboard navigation; add selected directory as a DSH workspace, customizable sidebar display name; removing a workspace from the sidebar only performs local unregistration and does not affect the remote directory.
• Session identification. Remote sessions come with header capsules, sidebar colored badges, and hover rows; local sessions are unaffected.
• Console. Console provides a machine bar, host overview, statistics, workspace cards, recent sessions, search, and a remote file browser supporting download, save to local, and locate in system.
• Terminal. The remote terminal is a full xterm.js terminal (PTY channel), supporting colors, cursors, full-screen programs, paste, and scrollback buffer.
• Port forwarding. Automatically discovers remote listening ports, one-click forwarding, configuration is persisted and restored after reconnection.
• Theme. Theme follows DSH’s theme tokens; both light and dark modes are supported.
• Dependencies. The plugin has no npm dependencies: ssh2 and its dependency tree are placed in vendor/node_modules, terminal resources are in vendor/xterm, so the installation process does not execute package build scripts.

Architecture: Remote Only Needs SSHd¶

The architecture diagram given in the README is as follows: DSH desktop runs sessions, sidebar, and the Remote Deck console on the host side, while the plugin provides a connection pool, workspace stubs, and a loopback API on the remote side; both sides communicate via SSH, specifically exec channels (running commands), SFTP (files), PTY (terminal), and direct-tcpip (port forwarding).

This implementation is worth mentioning because it determines what you can and cannot do. The remote workspace is actually a marked stub directory under <DSH_HOME>/remote-deck/workspaces, where the mark records the connection ID and the remote POSIX path. All path requests under this directory are resolved via SFTP, commands are executed via exec channel in the remote cwd, ripgrep is moved to the target host for execution, the terminal is a PTY channel, and forwarding is implemented via a local listener for each port.

In other words, no agent needs to be deployed on the remote side, nor does it require package installation; the cost is that the capabilities provided by the SSH protocol itself are the boundaries of the plugin’s capabilities.

Installation and Enablement¶

This step installs the plugin into DSH. The official README provides four installation paths; choose one based on your environment.

1. NPM Name (Recommended)¶

Plugin Market (after listing) or npm:

dsh plugin add dsh-remote-deck

2. Install from GitHub¶

dsh plugin add git+https://github.com/dsh-plugins-cn/dsh-remote-deck.git

3. Using a Proxy for Domestic Networks¶

In mainland China, the README provides a GitHub proxy:

dsh plugin add "git+https://ghproxy.laiyouxi.com/https://github.com/dsh-plugins-cn/dsh-remote-deck.git"

4. Install from Checkout¶

If you have already cloned the repository locally, the steps given in the README are to run install.ps1 in the cloned directory:

git clone https://github.com/dsh-plugins-cn/dsh-remote-deck.git
cd dsh-remote-deck
powershell -ExecutionPolicy Bypass -File .\install.ps1 -Profile desktop

After installation, please restart DSH or press Ctrl+R. Afterwards, an SSH status chip will appear at the bottom of the sidebar, and “Remote Development” will appear in the sidebar navigation.

Screenshots in the README come from desensitized design documents in docs/design/v2/, with hostnames, addresses, and paths being demo data (dev-box, 203.0.113.10, /srv/demo-app).

Environment Requirements¶

DSH desktop 0.2.x or higher; Node 20+; remote host must have sshd, operating system is Linux or macOS, remote shell is bash.

Migration from dsh-remote-ssh¶

Remote Deck is the successor to dsh-remote-ssh. The README lists several noteworthy points:

• On first load, it copies connections from <DSH_HOME>/remote-ssh and reuses existing workspace stubs in place, so the positions of workspaces and sessions in the sidebar remain unchanged.
• The old plugin continues to work before deletion. Both plugins patch ctx.fs, so only one can be enabled in a single profile.
• Switching is done with a single command; the script backs up package.json and retains old plugin files for rollback:

.\install.ps1 -Profile desktop -RemoveOld

• Rollback at any time:

.\install.ps1 -Rollback   # Restores package.json.bak-before-deck

Data is stored in <DSH_HOME>/remote-deck, and reinstalling the plugin will not cause data loss.

Typical Usage¶

The following walks through the steps described in the README in order.

1. After installing the plugin and restarting DSH, an SSH chip appears in the sidebar. Click to enter the Remote Deck console.
2. Add a machine. Authentication supports key and password; passwords and key passphrases are stored in the DSH credential store, not connections.json, which is explicitly stated in the README. Connection dialogs allow testing the connection, showing the remote OS and latency.
3. Use breadcrumbs and filters in the remote folder browser to find the target directory, e.g., the root of a service repository, add it as a workspace, and give it a sidebar display name.
4. Open a DSH session in this workspace. The agent’s read and write operations fall on the remote directory, search uses remote ripgrep, and commands are executed based on the current directory. The session will have a color identifier in the sidebar.
5. Open the terminal (PTY) when interactive operations are needed. Standard full-screen programs and colored output are supported.
6. When accessing a service port listening on the remote side, check the auto-discovery results in Ports and forward with one click. The README notes that forwarding configuration is persisted and restored after reconnection. If auto-discovery is unavailable, manual forwarding still works.

Security Boundaries¶

These points are from the Security section of the README:

• Passwords and key passphrases only go into the DSH credential store; they do not appear in connections.json.
• Communication between the browser side and host side is via a loopback HTTP server, protected by a per-session token.
• Terminal and port forwarding entry points are hung under the same token.
• Removing a workspace only performs local unregistration; the plugin will not delete remote files.

Known Limitations¶

The README lists four items itself; it is worth knowing them before use:

• The xterm.js used for the terminal is a vendored build. If the asset loader is intercepted, the plugin degrades to a plain text line renderer.
• The UI prioritizes Chinese; English strings are planned to be added in v1.1.0.
• Importing ~/.ssh/config covers fields like Host / HostName / Port / User / IdentityFile / ProxyJump, but proxy commands and host-key pinning are not yet integrated into the connection dialog.
• Auto-discovery of ports depends on the remote side having ss or netstat; without them, manual forwarding still works.

Use Cases and Notes¶

Who is it suitable for: DSH desktop users who need to develop or perform operations on Linux/macOS remote machines, wish for the agent to directly manipulate remote files and commands while preserving DSH session context, and do not wish to deploy agents on the remote side. Users migrating from dsh-remote-ssh can also switch directly.

A few reminders:

• The plugin runs within the DSH desktop process, accessing the local file system, loopback HTTP ports, and SSH outbound connections using the current DSH process permissions. Please check the source code and license before installing—the repository license is MIT, version 1.2.7 (from package.json in the repository).
• Only enable either Remote Deck or dsh-remote-ssh in a single profile; both patch ctx.fs.
• Star count and directory category belong to the current state; you can check the repository page again before integrating.
• The remote side needs sshd and a shell of bash; automatic port discovery also needs ss or netstat.

Conclusion¶

The value of Remote Deck lies in combining “local workspace” and “remote machine” into the same DSH window, eliminating the need to install agents remotely or maintain synchronization and port forwarding manually. The functional boundaries are determined by the SSH protocol, and the README clearly outlines known limitations, which is worth reading before integration.

Directory page: https://www.skillhub.cn/plugins/dsh-plugins-cn/dsh-remote-deck
Repository: https://github.com/dsh-plugins-cn/dsh-remote-deck

The development README also provides three commands for self-testing by plugin developers: npm run check (syntax and manifest check), npm test (parser unit tests), and npm run pack:dry (view the list of files to be published).