Preface¶

DeepSeek Harness (abbreviated as DSH) is an open-source agent runtime developed by DeepSeek, with the core concept of “everything is a plugin”: models, tools, sessions, sandboxes, file systems, and interfaces can all be mounted and replaced. The repository address is https://github.com/deepseek-ai/deepseek-harness. There is an independently maintained plugin directory in the community at https://deepseek-harness-plugin.com/en-US/plugins/, which is not the official app store of DeepSeek / Horizon Robotics. The listed entries need to be verified against GitHub and npm again.

DSH’s web interface deliberately only listens on 127.0.0.1, and the CLI will also reject --host 0.0.0.0. The local harness is very secure, but daily code is often not on the local machine: build machines, development containers, and lab servers have complete projects. The common practice at this time is to open another SSH terminal or maintain a synchronization script by yourself. dsh-remote takes another approach: you actively connect to the machine you maintain, select a remote directory as the workspace, and then let the Agent use a set of rw_* tools to list files, read code, and run commands there.

The current npm version is: 0.5.7 (updated on 2026-08-16). The GitHub repository https://github.com/flymysql/dsh-remote was verified to have 17 stars on 2026-08-17, with MIT license and JavaScript as the main language. The community directory categorizes it under “Tools and Capabilities”.

What is this¶

dsh-remote is a DeepSeek Harness remote workspace assistant maintained by flymysql. It does three things: connect to a remote host via SSH (using private key or password); select a remote directory as the workspace; use rw_* tools to operate this directory, and mirror it to a local real directory via SFTP so that DSH’s native workspace can adopt it.

The plugin is declared as a normal bundle without modifying the dsh-workspace core. The client injection targets in package.json are @deepseek-ai/dsh-client-runtime and @deepseek-ai/dsh-client-ui-workspace, with platform set to web, and the peer dependency aligned with DeepSeek Harness ^0.1.0-rc.6. That is to say, it is a remote workspace plugin for the web interface, not moving the entire harness to run remotely.

Core Functions¶

The capabilities that match between the repository README and the current lib/index.js are as follows.

1. Multi-machine SSH registration. There is a “Remote Workspaces” section in the settings page: you can add, delete, and modify multiple hosts (host / port / user, using private key or password for authentication), and set the current machine. The password is only stored locally and will not be displayed on the interface. You can use “Test Connection” before saving to verify whether the host, user, and credentials are available.

2. Dual-tab workspace selector. It fills into the native “Add workspace / Select workspace” process, with a centered popup window, which defaults to the “Local” tab:

   • Local: Use the host’s system folder dialog or directly enter a local path to get an ordinary DSH local workspace, which can coexist with remote workspaces.
   • Remote: First select a machine, the path box pre-fills / and completes directories in real time; click one level to list the next level immediately, similar to system file selection or VS Code. There is also a “Browse…” overlay, which only fills the input box when selected and does not submit directly. After review, click “Set as Remote Workspace”.

3. Local mirror + bidirectional SFTP. After confirming the remote directory, the plugin will create a real mirror directory on the local machine (the README is located in ~/.dsh/remote-workspaces/), which can be passed through fs.realpath, and the harness will adopt it as a normal workspace. rw_sync pulls from the remote to the mirror, and rw_push pushes the mirror changes back. In the current implementation, rw_sync defaults to a depth of 5 and a maximum of 500 files (depth limit 8, file limit 2000); rw_push also has a file count limit. Do not default to “full library lossless synchronization” for large repositories.

4. rw_* tools for models, currently registered with these names:

You don’t need to modify the mirror first and then rw_push for single-file changes: rw_write_file will directly write to the remote via SFTP. Currently, user@host:/path will also inject a system prompt to let the Agent know the working root. A slash command /remote is also registered in the source code to view the connection status.

5. No longer secretly reading the default private key for credentials. CHANGELOG 0.5.5 clearly states: it will no longer implicitly read ~/.ssh/id_rsa. The current source code is also consistent —— privateKeyPath will only be used when explicitly provided; when there is neither a password nor a private key path, the connection will fail and prompt no credentials: set a password or a privateKeyPath to connect. The README configuration table still says “empty defaults to ~/.ssh/id_rsa”, which is inconsistent with the behavior after 0.5.5. Please refer to the source code and CHANGELOG.

Installation and Activation¶

The installation command given on the community directory page is:

dsh plugin add github:flymysql/dsh-remote

The directory also states that the plugin runs with the permissions of the current dsh process, and may execute code during installation; if you need reproducible installation, you should pin the commit hash:

dsh plugin add github:flymysql/dsh-remote#<commit>

Replace <commit> with the actual commit hash in the repository, do not leave the placeholder.

The repository README also includes the method of installing via npm bundle and specifying the profile. This plugin’s client only declares web, so it is generally installed into the web profile during actual use:

dsh plugin --profile web add dsh-remote
dsh plugin --profile web list
dsh --profile web

When dsh is not in the PATH, you can use:

npx --yes @deepseek-ai/dsh plugin --profile web add dsh-remote
npx --yes @deepseek-ai/dsh --profile web

The default web interface address is http://127.0.0.1:3080. After successful startup, “Remote Workspaces” will appear in the settings; “Add workspace” will have two tabs: “Local” and “Remote”.

You can also run npm install dsh-remote, and then add - id: dsh-remote / name: dsh-remote in cordis.patch.yml. During development iteration, the README allows adding the locally checked-out directory to the profile, and then use dsh plugin --profile web remove dsh-remote to revert to the released version after testing.

Typical Usage¶

Follow the repository’s “Quick Start” below, without additional custom scenarios.

1. Add a machine. Open Settings → Remote Workspaces, fill in host, port, user, and password or private key path, and optionally set it as the current machine. Click “Test Connection” before saving.

2. Select a workspace. Click Add workspace in the sidebar or session:

   • Local: System folder selection, or enter a local path.
   • Remote: Select the machine, browse to the target directory (or directly enter the absolute path), and click “Set as Remote Workspace”. The plugin will create and adopt the local mirror.

3. Let the Agent work remotely. Use it as a normal workspace, for example:

rw_list_dir(path?)
rw_read_file(path, startLine?, endLine?)
rw_write_file(path, content)
rw_exec(command)
rw_sync / rw_push

rw_pick_workspace requires an absolute directory, and the remote path must already be a directory; after setting, the local mirror path will be given in the prompt, and it is recommended to first run rw_sync to pull the files down. rw_read_file defaults to a maximum of 2000 lines, and you can use startLine / endLine for pagination. rw_exec runs operations that do not read files on the remote, such as build, test, grep, etc., and the output has a limit (configuration item maxOutputChars, default 200000).

If you want to bring a default machine on startup, you can write the configuration in cordis.patch.yml. Below is the README example, the host uses the reserved documentation address, please replace it with your own machine; privateKeyPath must be explicitly provided, or use password instead:

# Example: please replace with your own machine
- id: dsh-remote
  name: dsh-remote
  config:
    host: 203.0.113.10
    port: 22
    username: dev
    privateKeyPath: ~/.ssh/id_rsa
    # Or use password login:
    # password: '…'
    workspace: ~/project

When host is empty, the plugin starts in a disconnected state, and you can configure the machine in the UI later. You can also see these configuration keys in the current source code: passphrase (passphrase for encrypted private key), commandTimeoutMs (default 20000), connectTimeoutMs (default 15000), maxOutputChars (default 200000). When the password is not empty, password authentication will be used, and the private key will no longer be read.

Applicable Scenarios and Notes¶

It is suitable for users who are already using the DSH web interface and whose code or build environment is on an SSH-accessible host: development machines, business machines behind a jump server, and lab servers are all acceptable. It solves the problem of “the harness stays on the local loopback, and the working directory is on the remote end”, and lets the Agent use the same workspace process to list directories, modify files, and run commands.

Before using, please note the following points, all from the directory page, README, and current source code, not speculation:

1. Permissions and installation security. The plugin runs with the permissions of the current dsh process, and may execute code during installation. You should check the source code repository and license before installation. This plugin is MIT licensed, and the source code is at https://github.com/flymysql/dsh-remote.

2. Handing over credentials to the plugin is equivalent to allowing the Agent to execute shell commands on that machine as your user. Only add hosts you trust. The password is stored in a local file, treat it as sensitive data, and tighten the file ACL if necessary. Use a private key if possible instead of writing a password into the configuration; also explicitly specify the private key path yourself.

3. Synchronization is bounded. rw_sync / rw_push have depth and file count limits, not unlimited mirroring. Do not default to “pull all at once” for super large repositories or a large number of binary files. Use rw_write_file for single-file modifications first.

4. Web-only. The client platform is web, and the peer dependency is the DSH 0.1.0-rc.6 generation of packages. Whether it is available for TUI or other profiles is not stated as supported in the repository.

5. Do not mix plugins with the same name. There are other SSH-based plugins in the community such as dsh-remote-ssh, dsh-ssh, dsh-remote-ide, which have different implementation methods and goals. This article only corresponds to flymysql/dsh-remote.

6. There was a startup regression recently. The CHANGELOG clearly states that versions 0.5.5 / 0.5.6 once changed the tool schema to a form that DSH’s value schema DSL did not accept, causing dsh web to fail to start after the plugin was installed; 0.5.7 (2026-08-15) has reverted to required: true on leaf attributes. Please confirm that you have obtained version 0.5.7 or later when installing for the first time.

Summary¶

DSH pins the web interface to the local loopback, which is a secure default; dsh-remote does not change this default, but lets you connect out from the local machine, harvest the remote directory into a workspace that can be adopted by the harness, and then use the rw_* tools to read, write, and execute on the remote end. It is maintained by flymysql, open-sourced under MIT license, and the current version is 0.5.7.

Directory page: https://deepseek-harness-plugin.com/en-US/plugins/dsh-remote/

GitHub: https://github.com/flymysql/dsh-remote

npm: https://www.npmjs.com/package/dsh-remote