Introduction¶

When running multiple tasks with DSH, a common failure mode is message routing errors: the user intended to supplement requirements for Task A, but the message entered Session B. The model continued execution based on B’s context, producing a bunch of operations irrelevant to the current task. By the time it’s discovered, some writes have already occurred, making it hard to distinguish which actions belong to this misrouting and which were executed normally earlier. Existing approaches either rely on humans monitoring the conversation or manually attributing issues by digging through logs after the fact, which is costly and prone to omissions.

The myboker/dsh-conversation-guard introduced below is a community plugin designed to intercept and track these events. It falls under the “Workflow” category. It does not replace DSH’s permission system but performs a task attribution judgment before the message enters the model.

What is it¶

dsh-conversation-guard is a standalone community plugin for DeepSeek Harness, maintained by myboker, licensed under MIT. Its function is to establish a task identity for a session and use a classification model to determine whether a batch of newly incoming messages belongs to that identity. If it suspects misrouting, an explicit task switch, or insufficient information, it pauses execution before running, requiring human confirmation. If work has already been done in the wrong session, the plugin can export a summary and evidence index of that work as a reviewable handoff record.

It is explicitly not an official component and does not promise compatibility with other DSH pre-release versions. The current community preview version is 0.1.0-rc.3.

Core Features¶

1. Task Identity Binding. The first human message in the session establishes the task identity; it can also be explicitly specified using /guard task Fix the web-auth login form. Subsequent suspicious messages cannot silently rewrite this identity. It is recommended to use a separate session for each task; when enabling the plugin in an existing long session, explicitly set the task first.

2. Batch Message Admission. The plugin hands over “current task, candidate messages, and limited context of up to four accepted batches” to the classification model. The default classification model is deepseek-v4-pro, API endpoint https://api.deepseek.com. Confirmations are performed in batches; it is not supported to release a single message within a batch separately.

3. Approval is not Authorization. Approval only indicates that this batch of messages belongs to the current session; it does not expand existing permissions, working directories, or Super-agent Mandates. Check failures, attachments, and oversized messages all require manual review.

4. Callback and Handoff. Before the model confirms, the plugin first persists the entire batch of messages to the database; they can then be reviewed via commands. When a user realizes work was done in the wrong session, the Agent can invoke conversation_guard_handoff to record a summary, executed actions, artifacts, verification status, external impacts or background tasks, and remaining work, and export a local Markdown with evidence citations.

5. Evidence Boundaries. Evidence is located via original message IDs, real model call boundaries, steps, tool call IDs, and task creation relationships, excluding subsequent irrelevant requests. If a model step handles multiple requests or old logs lack call boundaries, the record is marked as mixed. Activities not recorded with relationships will not be arbitrarily attributed by time order. The export freezes the evidence list; subsequent logs cannot secretly modify the report.

Installation & Enablement¶

The plugin is released in tgz format. First, download dsh-conversation-guard-0.1.0-rc.3.tgz from the GitHub Release, then install and check the configuration using the commands below. Installation creates a profile (guard-demo) based on the DSH default template. Please use an unused name, as --from-default-profile will overwrite a profile with the same name.

dsh plugin --profile guard-demo add /absolute/path/dsh-conversation-guard-0.1.0-rc.3.tgz
dsh --profile guard-demo --dump-config

If an interactive interface is needed, first create a profile from the official web or tui template, then install the plugin:

dsh --profile guard-demo --from-default-profile web --dump-config
dsh plugin --profile guard-demo add /absolute/path/dsh-conversation-guard-0.1.0-rc.3.tgz

The key for revoking the classification model is read from an environment variable at startup and is not written into the plugin configuration. To set DEEPSEEK_API_KEY in the process environment where DSH is started, run dsh --profile guard-demo afterwards. Saving the Key in the DSH Models page does not set the environment variable for the classifier.

Classifier-related configuration is written in the profile’s cordis.patch.yml, with overridable fields as follows:

- id: conversation-guard
  config:
    stateDirectory: /absolute/private/path/conversation-guard
    apiKeyEnv: DEEPSEEK_API_KEY
    model: deepseek-v4-pro
    baseUrl: https://api.deepseek.com
    timeoutMs: 30000
    questionTimeoutMs: 45000

Environment requirements: Node.js 24.9 or higher, DSH 0.2.2-alpha.3 or 0.2.2-rc.1 (consistent with the engines field in package.json and the README description).

Typical Usage¶

After enabling the plugin, messages that are suspicious before the first batch is executed by the model are saved as a batch first. An interactive interface that supports native prompting will show a confirmation prompt. If there is no prompting interface or the prompt times out, the messages are still retained and can be processed via commands:

Sending just a single “continue,” a paragraph of tool output, a paragraph of quoted text, or a confirmation token from another session cannot authorize a batch of messages. New messages received during the suspended batch period are merged into that batch and replace its confirmation token, thereby preserving dependencies like “do as I said above.” To switch tasks, first cancel the suspended batch, then set a new goal and submit a new task.

Evidence browsing for handoff records supports pagination:

/guard evidence HANDOFF_ID
/guard evidence HANDOFF_ID index:20
/guard evidence HANDOFF_ID 3:0

The first line shows the index, index:20 jumps to the next page index. The record’s read_cursor points to the body text, and next_cursor points to the next segment. The body text of each page is up to 4000 characters; long outputs can be read in pages without truncation. The index page has a maximum of 20 entries. The original complete logs remain in DSH, while the plugin stores citations rather than copying the entire text. Evidence can only be queried from the source session and requires both the original DSH logs and the plugin database; records that have been deleted or modified will be reported as unavailable.

Applicable Scenarios & Notes¶

It is suitable for use when running multiple tasks in parallel or when a single session handles different goals for a long time, especially in scenarios where “which actions were caused by which request” needs to be defined after a misrouting occurs. Its handoff export provides a reviewable summary and evidence citations, rather than a full transcription. The Demo recorded in the README explicitly states that the runtime and plugin are running for real, while the classifier and worker responses are scripted; therefore, this is not a demonstration of model accuracy.

Note a few points before use: The plugin runs with the permissions of the current DSH process; approval only confirms message attribution and does not change permission boundaries. Its design requires tasks to be clearly distinguished within the session; when enabling the plugin in an existing long session, explicitly set the task first. After a restart, residual messages will not be executed automatically and need to be judged by returning to the original session and using /guard status. Test data is synthetic; the plugin only declares compatibility with the two DSH pre-release versions mentioned above and Node.js 24.9+. Before installation, you should check the plugin source code and license.

Conclusion¶

dsh-conversation-guard solves a specific problem: which task session messages belong to, and how to hand off after misrouting. It puts the tasks of “determining whether to allow” and “leaving a reviewable record of evidence” into the same set of commands, without needing to change DSH itself or existing workflows. The project directory page is at https://www.skillhub.cn/plugins/myboker/dsh-conversation-guard , and the source code and Release are at https://github.com/myboker/dsh-conversation-guard .