DeepSeek Harness plugin

dsh-bridge

Local session messaging and event bridge for DeepSeek Harness

Jump to install

Source facts

Repository
baixianger/dsh-bridge
Latest update
Aug 18, 2026
Category
Tools & Capabilities
GitHub stars
0
Format
plugin
Catalog evidence
Upstream dsh.bundle evidence
Evidence path
package.json#dsh.bundle
Checked against
0.1.0-rc.8
Upstream check date
2026-08-20

This evidence comes from the upstream catalog. This site has not installed, run, or security-reviewed the plugin.

Install

Start with a prompt that asks an agent to review the GitHub repository and source. Switch to the command if you want to install it yourself.

Copy this prompt into DSH, Codex, or another agent and ask it to review the GitHub repository and source first.

Do not install or run any commands yet. Read this plugin's GitHub repository, README, and relevant source code. Then answer the questions below clearly and directly so I can decide whether it fits my needs:

1. What is this plugin, and what problem does it solve?
2. Who is it for, and what are its typical use cases?
3. How is it used after installation? Include one minimal example.
4. What known limitations or privacy, security, compatibility, or maintenance risks does it have?
5. Give a clear recommendation: recommend, conditionally recommend, or do not recommend, with reasons.

Distinguish statements documented by the repository, inferences from source code, and unknowns. If evidence is insufficient, say so explicitly. Do not guess or simply repeat the README.

GitHub: https://github.com/baixianger/dsh-bridge
Plugin: dsh-bridge
Author: baixianger

Check the source files

Read the README and other files from this plugin directory before installing.

File explorer2 files
README.mdSource · read only

dsh-bridge

> Local, cross-session messaging for DeepSeek Harness.

DSH Bridge is the local messaging foundation of the DSH family. It lets live sessions in one DSH host discover one another and exchange messages. It has no Web UI and no network transport.

dsh-weave can extend Bridge across machines; dsh-chat can present its messages as a human-facing group chat. Neither is required for local use.

The plugin exposes the ctx.dshBridge service and registers session_list, session_send, and session_messages for agents. The old ctx.sessionMessaging accessor remains as a temporary compatibility alias.

ctx.dshBridge.deliverExternal() is the controlled inbound seam for a trusted transport such as Weave: it emits the same session follow-up and audit record as local delivery, rather than letting a transport manipulate agents directly. Delivery uses the public ctx.agents registry and Agent.followup(). An idle target is woken, a running target receives ordinary queued work, and a persisted offline target is resumed through DSH's configured Host agent resolver before delivery. Concurrent messages to the same cold session share one resume operation. The resolver reconstructs the recorded agent preset and model selection exactly as the Web host does. A bounded in-memory recent log (the latest 1,000 delivered messages) is kept only for session_messages replay and diagnostics; it is not a second delivery queue. Messages carry sender, target, UUID, and timestamp metadata.

This package intentionally does not implement cross-host transport. dsh-weave will provide the authenticated network backend while preserving the local message semantics.

Install

dsh plugin --profile web add dsh-bridge@next

Known Limitations and Deferred Work

  • Process boundary — sessions in another process or host are not visible;

add an authenticated relay/backend before advertising cross-host delivery.

  • In-memory retention — messages are lost when the plugin process exits and

older than the latest 1,000 are evicted; durable inbox/outbox persistence is still deferred until a cross-process relay needs it.

  • Delivery acknowledgement — the current result means the target was live

(or successfully resumed) and accepted the follow-up call, not that the target model processed it.

Model Experience

None, as session_list, session_send, and session_messages expose their schemas directly through the tool registry.

KV Cache effect

Independent tool schemas; sending a message changes only the target session's queued input and does not alter the sender's cached prompt prefix.