Introduction¶

The message channels built into DSH have prerequisites: send_message only passes between direct parent-child agents, Agent Teams only between team members, and there is no path between two normal sessions in the sidebar. Wanting to perform cross-session handover (e.g., Session A asks Session B to check back on results and opens a new session to write the CHANGELOG), you could previously only rely on manual copy-paste. This plugin tonyzdev/dsh-session-messaging fills this missing link: it adds three tools to each top-level session—find session, send message, and create new session—received messages are marked with the source, and the recipient replies using the same tool. Below, I will introduce them in the order of Features, Installation, Usage, Settings, and Notes.

Plugin Identity and Source¶

• Maintainer: tonyzdev, community maintained, not DeepSeek official.
• Category: Workflow (classified as such in the community directory SkillHub).
• Community Popularity: GitHub 20 stars, 4 forks. It is a small community plugin with small and well-defined functional boundaries.
• License: MIT.
• Source and Release: https://github.com/tonyzdev/dsh-session-messaging, package name @tonyzdev/dsh-session-messaging.

This plugin does not call the model and does not require extra API keys; its value lies purely in the ability for sessions to “speak” to each other. Before installing, it is recommended to read the README and source code once to confirm that the forwarding behavior is exactly what you need.

Core Functions¶

Three tools with orthogonal functions, modifying DSH’s native session model.

1. session_list: Lists top-level sessions that can receive messages by recent activity. Returns id, running/idle, and title. By default, it only looks at the current workspace, but it can list all workspaces or search by title.
2. session_send_message: Sends a message to another session. Running sessions will read it in the next turn; idle sessions will start a new round immediately; stored (unloaded) sessions are restored before processing. When delivery: "queue" is used, it waits until the recipient finishes their current turn before starting a new round.
3. session_create: Opens a new session in the sidebar with a title, starting with your message. The new session works independently and cannot see the initiator’s conversation; to make it report back, write it clearly in the message.

Source marking is a separate step: received messages appear as user-side bubbles, with “From session ‘Title’” written at the top. The model sees a line of source information—indicating which session sent it, that it was written by the recipient’s agent rather than the user, and how to reply. The note at the end reminds the recipient not to reply just to confirm receipt, to avoid endless “Received” and “OK” loops between two sessions.

Boundaries are also explained within the functions; this will be expanded upon later.

Installation and Enablement¶

The only prerequisite is DeepSeek Harness 0.2.0+ (README mentions it has been tested on macOS 0.2.1-rc.5). The engines field specifies >=0.2.0-rc.1 <0.3.0-0.

Method 1: Let DSH Install It (Recommended)¶

Send the following sentence directly to any DSH session. The agent will automatically identify whether it is the desktop or web version to complete the installation and hot reload. Bash and PowerShell have different ways to get the profile, so the command writes both.

请帮我在当前 DSH profile 安装插件 https://github.com/tonyzdev/dsh-session-messaging：若有 plugin_manager 工具请直接调用 install_bundle 安装并启用；否则读取当前 profile 名（bash 为 $DSH_PROFILE，PowerShell 为 $env:DSH_PROFILE；为 desktop 时调用 app.asar 同级 runtime/cli/bin 下的 dsh 或 dsh.cmd，其他情况用 PATH 中的 dsh，受沙箱限制时申请全盘权限审批）执行 dsh plugin --profile <profile> add github:tonyzdev/dsh-session-messaging，不要手改配置文件或重启宿主。

Method 2: Manual Install via UI¶

Open Plugins → Add Plugin in the sidebar, enter the full repository address, click Install, and then Enable immediately. If the forwarding bubble style hasn’t appeared yet, press ⌘R / Ctrl+R to refresh the page.

https://github.com/tonyzdev/dsh-session-messaging

README specifically reminds: You must enter the full GitHub repository address here, do not just enter dsh-session-messaging. The same-name package without a prefix on npm is maintained by another author; installing the wrong one is not this plugin.

Command Line and Pre-packaged Installation¶

For the web version, use profile web:

dsh plugin --profile web add github:tonyzdev/dsh-session-messaging

For the desktop version, use the application’s built-in CLI (path depends on platform). macOS:

DSH="/Applications/DeepSeek Harness.app/Contents/Resources/runtime/cli/bin/dsh"
"$DSH" plugin --profile desktop add github:tonyzdev/dsh-session-messaging

Windows (PowerShell):

& "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\runtime\cli\bin\dsh.cmd" plugin --profile desktop add github:tonyzdev/dsh-session-messaging

README notes that running --profile web on a machine with Desktop installed only installs into profiles/web, not appearing in the Desktop UI. To use Desktop, use the built-in CLI pointing to --profile desktop above, or install directly in the UI.

You can also install a pre-packaged Release .tgz without performing a full Git pull:

dsh plugin --profile web add https://github.com/tonyzdev/dsh-session-messaging/releases/download/v0.3.2/tonyzdev-dsh-session-messaging-0.3.2.tgz

For local development, use the link method for installation so code changes directly affect that copy:

git clone https://github.com/tonyzdev/dsh-session-messaging ~/.dsh/local-plugins/dsh-session-messaging
"$DSH" plugin --profile desktop add link:$HOME/.dsh/local-plugins/dsh-session-messaging

Removal method:

"$DSH" plugin --profile desktop remove @tonyzdev/dsh-session-messaging

Apply a Patch Configuration¶

Change configuration via the profile patch file; do not manually edit other configurations. The desktop patch path is ~/.dsh/profiles/desktop/cordis.patch.yml. Write only the fields to change; defaults apply to missing ones:

- id: session-messaging
  config:
    crossWorkspace: false

Takes effect after saving; if it doesn’t work, restart DeepSeek Harness.

Typical Usage¶

You don’t need to memorize the tool names; just tell the agent what to do. The three sentences below are from README examples and can be copied directly into a session to try:

问问「修复登录超时」那个会话：bug 修好了吗？改了什么？

告诉「前端重构」那个会话：接口字段 user_id 改名为 uid 了。

开一个新会话，让它把这条修复写进 CHANGELOG.md，写完告诉我。

Corresponding to tool parameters, this table is clearer:

One point to clarify: Tools only return delivery confirmation, not the recipient’s answer. The answer returns as a new message in the sender’s session, readable from the bubble or the next turn.

Settings¶

README provides four configurable items, with defaults as follows:

To tighten cross-workspace access, simply set crossWorkspace to false; this is the only item in the default value you might want to change.

Implementation (Brief)¶

Explaining the implementation is to clarify why some limits exist and to help you judge if you can extend them.

Message forwarding uses sessionController.resolveAgent, the same path as sending a prompt in the web version, restoring sessions from cold storage if necessary. Messages carry DSH’s built-in forwarding source { kind: 'agent-message', form: 'relay', senderSessionId } and are written into the recipient’s session log. The browser side overrides the Chat turn-trigger renderer, only handling messages forwarded by this plugin, reusing DSH’s built-in conversation.chat.user.content bubble; other trigger messages like targets, scheduled tasks, and sub-agents still go through native cards. Therefore, the content the model receives remains unchanged, only the display changes.

Opening a new session uses sessionController.create({ workspaceId }), which is the path for “New Chat” in the web version. The title is fixed before the first turn starts because forwarding messages do not trigger DSH’s automatic title generation—this also explains why the title set by session_create is not automatically rewritten later.

Main file mapping:

Sub-agents use agent.ctx.tools.restrict({ deny }) when agent/created to hide these three tools, so sub-agents cannot receive replies through this channel.

Known Limitations and Mitigations¶

These are explicitly listed in README, determining what scenarios are suitable for using it.

1. Woken or newly opened sessions run according to their own settings. New sessions use the default model and default approval strategy (mentioned as ask in README), not inheriting the initiator’s settings. If they need approval, the approval request stops there, possibly unattended.
2. Communication only happens between top-level sessions; sub-agents and Team members still use DSH’s native send_message.
3. “Delivery” only means the recipient’s inbox accepted the message, not that it has been processed; there are no retries, deduplication, or read receipts.
4. When a recipient is running, received messages are merged into their current turn; the model can receive them, but they are not displayed as bubbles; only messages from woken sessions are displayed as bubbles.
5. Bubbles do not render Markdown, nor do they fold long messages.
6. There is no frequency limit on sending messages; preventing small talk relies on the prompt in the source note. createLimit exists in memory and resets to zero after plugin reload or restart, and does not limit chains like “A opens B, B opens C”.
7. The title set by session_create is fixed like a manual rename; DSH will not automatically change it later.

Suitable Scenarios¶

Suitable for these situations:

• Top-level agents needing cross-session handover. For example, one session specializes in code changes, another in release preparation, the former writes the results in a message, and the latter wakes up to read.
• Wanting to spawn independent tasks. The main session opens a new session to write documentation or run an independent validation without exposing its own conversation context.
• Wanting to orchestrate using natural language instead of tool calls: “Ask that session if it’s fixed.”

Not suitable for these situations:

• Workflows requiring guaranteed reliable replies. There are no retries or deduplication; messages might be lost or arrive in the middle of a turn.
• Sub-agents needing to send/receive messages. This channel does not cover sub-agents, still using DSH’s native send_message.
• Scenarios requiring approval isolation need caution. Woken sessions use the default approval strategy and might stall waiting for someone.

Conclusion¶

One-sentence recap: tonyzdev/dsh-session-messaging adds a shortcut path between DSH top-level sessions, adds three tools, downgrading cross-session handover from manual copy-paste to a single natural language sentence, at the cost of preserving DSH’s original top-level boundaries and bringing a few clear capability boundaries. If your workflow truly needs “A asks B, B spawns C”, install it via the method above, test a round, and confirm the limitations match your expectations before integrating into the routine.

• Directory page: https://www.skillhub.cn/plugins/tonyzdev/dsh-session-messaging
• GitHub: https://github.com/tonyzdev/dsh-session-messaging