Preface¶

DeepSeek Harness (dsh) treats models, tools, sessions, and loops as plugins, with the official repository’s slogan being “Everything is a Plugin”. It works smoothly for single-instance deployments: one process, one set of sessions, and one toolkit. However, when you need to run two machines, two web services simultaneously, or have one agent hand off results to a session on another machine, its default capabilities fall short — there are no built-in message channels between instances, nor any health checks or event synchronization.

dsh-interconnect is a community plugin that fills this gap. It attaches cross-instance HTTP/WebSocket services to the host, and exposes two tools interconnect_send and interconnect_ping for models, allowing one DSH instance to send messages, probe liveness, and bidirectionally push lifecycle events to the local machine, another machine, or another DSH instance on a different machine.

This article is collated against the community plugin directory page, GitHub repository README, source code, and npm page. The community directory deepseek-harness-plugin.com is an independent site, not an official app store for DeepSeek/HyperGAN; the plugin itself is maintained by GitHub user Chinesezjc under the MIT license.

What is this¶

dsh-interconnect is a workflow and automation plugin. Its current npm version is 0.2.0, and it is primarily written in TypeScript. The repository was created on 2026-08-13, with the latest push being Release 0.2.0 on 2026-08-14. The community directory showed 26 stars when it was listed on 2026-08-15; as of the GitHub repository query on 2026-08-17, it had 30 stars.

It solves cross-instance handoffs, not multi-agent orchestration within a single process. The repository splits its capabilities into two Cordis plugins, which are installed together as a profile bundle:
- interconnect: A host-level service registered as ctx.interconnect. It exposes external /interconnect/* HTTP endpoints and a /interconnect/link WebSocket, and internally handles message delivery, health checks, and event fan-out.
- tool-interconnect: Model-visible tools. interconnect_send delivers text to a specified session on a peer; interconnect_ping checks if a peer is reachable and its reported instance identity.

Both ends use the same shared secret DSH_INTERCONNECT_TOKEN for Bearer authentication. If the token is not configured, incoming requests will be directly rejected (fail-closed), and comparisons are performed in a timing-safe manner.

Core Features¶

Host Service: HTTP Delivery and Health Checks¶

The interconnect plugin manages routing directly on the host webserver, bypassing the Connection RPC channel. The source code comments explain why: RPC handlers cannot access the Authorization header, and the trust boundary for this service is the Bearer token.

All HTTP endpoints use POST requests, require Content-Type: application/json, and use the /interconnect path prefix:

The request body reuses the DSH host API’s client-request envelope: type, rpcId, method, payload. The method must match the last segment of the path, otherwise a bad-request response will be returned. The maximum request body size is 1MB.

send only delivers messages to currently running agents. If the target session does not exist or has been destroyed, it will return delivered: false and will not create a session out of thin air. The source of messages delivered to the inbox is:

{ kind: 'plugin', plugin: 'dsh-interconnect' }

Not { kind: 'user' }. The receiving party uses this to distinguish between “cross-instance handoffs” and “local user input”. This is a behavioral change from version 0.1.0 to 0.2.0, marked by the minor version bump in the repository.

The delivery method is determined by the configuration item delivery, which defaults to followup:
- followup: Wake up the target agent and start a new turn to process this message
- inject: Only write to the model’s visible context without waking it immediately; the message may only be picked up at the next step boundary, and may be missed by already claimed steps

WebSocket Link and Event Fan-out¶

/interconnect/link is a persistent WebSocket. Authentication also uses Bearer tokens. There are only two types of application frames on the link: hello (the dialing party reports its own sender) and event (pushes a notification). Heartbeats use the WebSocket protocol’s built-in ping/pong mechanism, with a 30-second interval, and no additional application-layer keepalive is implemented. The link will automatically reconnect with exponential backoff after disconnection.

The host will listen for a set of local events and fan them out to subscribed peers. The serialized kind values in the source code include:
- agent/created, agent/disposed, agent/status (idle / running)
- session/created, session/disposed
- subagent/end (only for local in-process sub-agents)

When a peer receives the event, the local instance will emit an interconnect/event. Both HTTP subscriptions and WebSocket push streams are supported: you can configure a peers list in the settings during startup; you can also subscribe/unsubscribe at runtime, or call link(peer) to establish a persistent connection.

Model Tools: Let Agents Perform Handoffs Themselves¶

tool-interconnect exposes service capabilities to models without sending HTTP requests on its own. Tool parameters come from the source code registry:

interconnect_send
- baseUrl: Peer origin, e.g. http://127.0.0.1:3080 or http://peer-host:9001
- sessionId: Session ID on the peer to deliver the message to
- text: Message body

Returns { delivered, instance } on success.

interconnect_ping
- baseUrl: Peer origin

Returns { reachable: true, instance } if reachable; returns { reachable: false } if transmission or authentication fails.

Both plugins are attached to the host composition. interconnect is a process-level service and must be hosted at the host level; tool-interconnect is also placed on the host because currently there is no TypeRT @Remote/Gateway binding, and if placed in an isolate realm of an agent preset, the tool declarations cannot be injected into this service.

Installation and Activation¶

The installation command given on the community directory page is (as per the original page text):

dsh plugin add github:Chinesezjc/dsh-interconnect

For reproducible installations, pin the commit hash. The latest commit on the current main branch as of 2026-08-14 is 75488fbc4cbfef180e3f36a24438b42f00f43c5c (Release 0.2.0):

dsh plugin add github:Chinesezjc/dsh-interconnect#75488fbc4cbfef180e3f36a24438b42f00f43c5c

The repository README also covers installation from npm or a local path. The package name is dsh-interconnect, and the tarball on the registry includes lib/*.js and type declarations, with no build step required during installation:

dsh plugin --profile <name> add dsh-interconnect

dsh plugin --profile <name> add file:/path/to/dsh-interconnect

dsh plugin add will recognize the repository as a bundle, insert two plugins based on the root cordis.patch.yml, and append them to the profile’s dsh.profile.bundles. The default configuration in the patch is:

- insert:
  - id: interconnect
    name: dsh-interconnect/interconnect
    config:
      instanceId: dsh
      requestTimeoutMs: 10000

  - id: tool-interconnect
    name: dsh-interconnect/tool-interconnect

The instanceId will be echoed in ping/send results, and is only used for diagnostics and not involved in routing. When multiple instances coexist, it should be changed to a value that can distinguish them. The default requestTimeoutMs is 10000, with a maximum of 60000. You can also add these optional configurations as needed:
- peers: A list of peer origins to fan out to at startup, defaulting to empty
- delivery: followup or inject, defaulting to followup

After installation, you need to restart the web service for the host-side changes to take effect. Then configure the same DSH_INTERCONNECT_TOKEN in the .credentials.yaml (or equivalent credential source) of both instances. The token is a shared secret: anyone who possesses it can inject messages into the peer’s active sessions. Do not commit it to repositories, and do not reuse it between groups of mutually untrusted instances.

Typical Usage¶

The following parameters and envelope formats come from the repository source code and unit tests, and can be understood as-is. Do not copy the addresses, session IDs, and tokens in the examples directly into production environments.

1. Probe Liveness First, Then Deliver Messages¶

On the agent side, first call interconnect_ping against the peer origin, then call interconnect_send. The call shape in the unit tests is:

interconnect_ping
  baseUrl: http://127.0.0.1:3080

interconnect_send
  baseUrl: http://127.0.0.1:3080
  sessionId: sess-1
  text: Build completed, artifacts are in /tmp/out

The target session on the peer must already exist and have an active agent. This plugin does not handle “creating a new conversation” on the peer.

2. Direct HTTP Health Check Without Model Tools¶

Without going through model tools, you can also send a POST request directly to the host. The envelope format for outgoing requests in the source code is as follows (replace rpcId with your own UUID and the token with the value from your credentials):

curl -X POST http://127.0.0.1:3080/interconnect/ping \
  -H 'content-type: application/json' \
  -H 'Authorization: Bearer <DSH_INTERCONNECT_TOKEN>' \
  -d '{"type":"client-request","rpcId":"00000000-0000-0000-0000-000000000001","method":"ping","payload":{}}'

Requests will be rejected if the token is not configured, the token does not match, or the Content-Type is not JSON. This is by design, not an installation failure.

3. Bi-directional Event Sync Across Machines¶

After both machines have installed the same bundle and configured the same token, add the peer origin to the peers list or call link to connect to the peer at runtime. Local agent status changes will be pushed to the peer, and inbound events from the peer will be emitted as interconnect/event. The repository README states that the maintainer has tested message delivery, WebSocket event pushing, and agents sending reverse messages via interconnect_send between two machines. This is from the repository’s own documentation, not a third-party review.

The README also notes that currently 22 out of 22 unit tests pass (17 for the service, 5 for the tools). The CI will clone the public deepseek-ai/deepseek-harness repository as a sibling checkout before running pnpm run check.

Applicable Scenarios and Notes¶

It is suitable for these scenarios:
- Two DSH web instances on the same machine need to hand off task results to each other
- DSH instances on a development machine, build machine, or two servers need to perform health checks and message delivery
- You want to sync agent/session/local subagent lifecycle events to another side without polling logs yourself

It does not replace multi-agent orchestration plugins (such as dsh-agent-teams or dsh_workflow in the directory). Those plugins handle how to form teams and run workflows within a single Harness; dsh-interconnect handles the channel between instances.

Please note these points before use:
1. Permissions: The plugin runs with the permissions of the current dsh process, and may execute code during installation. Review the GitHub source code and MIT license before installing; pin the commit hash in production environments first.
2. Secrets: If DSH_INTERCONNECT_TOKEN is not configured, incoming requests will be fail-closed; once configured, treat it as a shared secret and protect it. Anyone holding the token can deliver text to the peer’s active sessions.
3. Network Exposure: The service is attached to the host webserver’s /interconnect path. If the web port is open to untrusted networks, this channel will be exposed as well.
4. Only Deliver to Active Sessions: If the peer agent is offline, delivered will be false, and it will not automatically start the agent.
5. Host-level Mounting: Do not expect it to work when placed in an isolated agent preset; the current architecture requires both plugins to be hosted at the host level.
6. Runtime Dependencies: ws is provided by the host’s node_modules (marked as external during build), and this package will not install a separate copy.
7. Version Fields: The npm/package.json version is 0.2.0; the dsh.plugin.json in the repository still shows 0.1.0. Refer to the npm version as the authoritative source.

Summary¶

dsh-interconnect fills the gap of cross-instance messaging, health checks, and event channels for DeepSeek Harness: the host side provides HTTP/WebSocket services with shared secret authentication, and the model side provides two callable tools. It has a small footprint and clear boundaries, making it ideal for users who are already running DSH across multiple instances or machines and need to hand off results instead of only orchestrating within a single process.

Community Directory: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-interconnect/

GitHub: https://github.com/Chinesezjc/dsh-interconnect

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