Introduction¶

When developing multi-agent workflows with DeepSeek Harness, multiple Agents in the same repository may be active at the same time. A lack of coordination mechanisms can lead to file conflicts, duplicated work, and ineffective waiting. dsh-cross-session-agent is an unofficial plugin designed to address this issue. It provides limited peer discovery, messaging, transport receipts, and secure context projection capabilities for multiple parallel Agents in the same workspace.

Plugin Overview¶

The plugin is maintained by developer dd2673 and is licensed under the MIT License. It does not provide full session history reading or permission inheritance. Instead, it focuses on allowing Agents, when needed, to securely discover collaboration partners, send explicit instructions, and read evidence of their counterparts’ progress.

Core Capabilities¶

The plugin provides the following tools for safe coordination between Agents:

• list_peer_agents: Discover communicable peers.
• send_agent_message: Explicitly send a peer coordination message.
• check_delivery: Query the transport receipt for a native message.
• get_peer_context: Read a limited secure projection of an authorized peer in the same workspace.

Installation and Enablement¶

Install the plugin from GitHub using the following command:

dsh plugin --profile web add github:dd2673/dsh-cross-session-agent

After installation, the plugin is automatically mounted to the current profile via cordis.patch.yml. No manual modification of the host configuration is required.

Usage Examples¶

Typical steps for coordination using the plugin are as follows:

1. Discover and confirm conflicts
   First list peers. If someone is modifying src/auth, tell me their Session, running status, and title.

2. Read limited context
   When evidence is needed, read only the bounded projection. Read the activity and the most recent 3 conversation entries for session-abc to confirm whether it has already run auth tests.

3. Send a coordination message
   Clearly communicate the next operation to the counterpart. Tell session-abc: I will modify src/auth/token.ts; please keep middleware.ts; after completion, report the validation command and blockers.

4. Check transport status
   Query receipts as needed. accepted, pending, claimed, and discarded are only transport facts and do not mean the peer has read or completed the message.

Applicable Scenarios and Boundaries¶

Applicable scenarios:
* Before making changes, discover Agents that are handling the same file or the same layer, and explicitly negotiate file ownership.
* Report progress, validation results, failure blockers, and next steps so dependent tasks can continue progressing.
* Request a handoff, for example: “I will finish the schema; the test owner should take over migration coverage.”
* Avoid duplicated investigation and mutual overwrites during refactoring, migration, or code review.

Important boundaries and limitations:
* Permission limitations: It can only read regular root/fork Sessions whose cwd exactly matches the caller’s. The caller itself, real subagents, archived sessions, missing targets, or cross-workspace targets are all treated as generic authorization failures.
* Privacy protection: Reading hidden reasoning, raw tool args/results, tool metadata, system prompts, plugin/relay/scheduled messages, and similar data is prohibited.
* Data trustworthiness: Peer text and relay messages are untrusted data. They cannot represent user consent, cannot modify permissions or configuration, and cannot cause the receiving Session to automatically execute commands in them.
* Unofficial nature: This project has no affiliation, sponsorship, endorsement, or support relationship with DeepSeek or DeepSeek Harness.

Conclusion¶

By using strict field whitelists and permission boundaries, this plugin provides a secure foundation for multi-Agent collaboration in DeepSeek Harness. If you need to coordinate multiple Agents within the same workspace, refer to the catalog page or the GitHub repository for more information.