Preface

After an agent is up and running, what’s truly hard to debug is not “whether it can call tools”, but “which events it actually observed in this turn”. DeepSeek Harness (dsh) treats models, tools, sessions, sandboxes and interfaces as replaceable plugins, and will continuously emit tool results and session events in one turn. If we persist all prompt texts, parameters and original results, auditing becomes convenient but the exposure surface also expands; if we leave no traces at all, we cannot answer afterwards: what categories of events did the agent see, what was the order, and whether the records were tampered with.

qiushi-dsh-evidence-audit takes the third path: only observe without modifying behavior, hash the normalized observation values into a SHA-256 hash chain, and write them into local JSONL. Plaintext prompts, tool parameters, tool results and session IDs are not stored by default, but stable audit categories such as event types and tool names are kept in readable form.

The official positioning of DeepSeek Harness is “everything is a plugin”, and it is currently in developer preview, so breaking compatibility changes are expected. The community site DeepSeek Harness Plugin Repository collects a number of extensions, which is an independently operated directory and has no affiliation, endorsement or sponsorship relationship with DeepSeek / HyperSpin. This article is collated after cross-checking with the directory details page, GitHub README / package.json / dsh.plugin.json, npm release page, and DeepSeek Harness official repository.

What is this

qiushi-dsh-evidence-audit is a session and message plugin maintained by 030611, licensed under MIT, and mainly written in TypeScript. Its positioning on the directory page is: a read-only hash chain evidence storage plugin for DeepSeek Harness —— you can audit what the agent actually did without changing its behavior.

The repository README explains it more specifically: it is an observe-only Profile Bundle that listens to the official extension points tools/result and session/event, and appends deterministic hash chain evidence receipts to JSONL. It will not register tools visible to the model, modify prompts, convert tool results, or append events to the session. The npm package name is also qiushi-dsh-evidence-audit, and the current released version is 0.1.0 (2026-08-13). As of 2026-08-18, both the directory page and GitHub show 5 stars.

The maintainer clearly stated in the README that this is a community project, not an official DeepSeek product. The same author also maintains related trust-layer plugins: dsh-telemetry-redactor, dsh-verification-receipt and dsh-context-provenance. The last two perform per-turn heuristic summarization and context provability reports respectively, and are not hash chain ledgers; do not confuse their capabilities with this plugin.

Core Features

Observe-only, no changes to model experience

Both listeners are contained observers: they do not return waterfall decisions, nor modify callback parameters. If receipt serialization or appending fails, only logs are recorded and isolated, and tool outcomes and session publishing will continue as normal. If startup fails, on the contrary —— when the output path is invalid or the existing hash chain is corrupted, the plugin will explicitly refuse to load, avoiding silent loss of audit records.

Therefore, prompt texts, tool schemas, tokens, model requests, results and KV-cache behavior will not be altered by it. The runtime cost includes canonical serialization, SHA-256 hashing, synchronous append I/O for each record, and full-chain verification during startup.

Local hash chain, no plaintext storage of content

The default file path is $DSH_HOME/evidence-audit/evidence-receipts.jsonl; if DSH_HOME is not set or empty, it uses ~/.dsh/evidence-audit/evidence-receipts.jsonl. The plugin will not write to the current working directory by default. When the operating system supports POSIX mode, the default directory permission is 0700 and the file permission is 0600.

Each line contains schemaVersion, sequence, collectedAt, previousRecordHash and recordHash. recordHash is the SHA-256 hash of the canonical JSON of all fields except itself; the next line uses previousRecordHash to commit the hash of the previous line, and the previous hash of the first line is null. During startup, the entire existing file will be verified. If any of the lines, sequence numbers, record hashes or previous links are invalid, appending will be refused.

The fields of the two types of receipts are different:
- session-event: session ID hash, event type, event sequence number and timestamp, event data hash, and optional ignorable flag.
- tool-result: tool name, call/root call/session ID hash, parameter hash, final outcome hash, error flag, parent call existence flag, and optional error code.

Event types and tool names are kept in plaintext because they are stable audit categories. eventDataHash, argumentsHash, outcomeHash are not anonymization, encryption or digital signatures: the JSONL does not store the original content, but offline hash collision is still possible for low-entropy candidate values. Receipt files should be protected as sensitive pseudonymous data.

Duplication is not removed for the two feeds. DSH may first publish a tool result via tools/result, and then publish it as a persistent tool/result session/event afterwards; the plugin will intentionally write two receipts to represent two observations. Do not aggregate them into “the tool was executed twice”.

What it can and cannot prove

The README clearly defines the boundaries:
- When verifying an existing file, it can detect: tampered preserved records, deleted unmodified prefixes, broken links, and trailing half-lines.
- It can explain: which event categories and hashes this observer saw in a certain local order.
- It cannot prove: correct command execution, authenticity of results, who generated the file; nor can it detect “the valid suffix was deleted in its entirety”.
- If the entire file is deleted and rebuilt, it cannot be distinguished from the first use without external anchors.
- An attacker who modifies and recalculates all subsequent hashes can bypass the self-contained key-free SHA-256 chain.

Hashes cannot be used as proof of authorship, nor are they external checkpoints. A successful writeSync does not equal fsync; power outages or storage failures may lose the last record. Multiple dsh processes must not concurrently write to the same file —— there is no cross-process lock, and detection only occurs during subsequent verification, which does not equal automatic recovery.

Compatibility is fixed to a commit, not a semver promise

The repository only claims that it was implemented and tested on 2026-08-13 against the deepseek-ai/deepseek-harness commit 47f943859bef60e4160492346772ded9b24f765a. This checkout marks the package version as 0.1.0-rc.5, but this version was not yet available on npm at the time of verification. Therefore, this is a commit-pinned statement, and does not mean support for 0.0.1-rc.1 on npm, subsequent DSH commits, or a certain semver range.

The official installer reads package.json#dsh.bundle.patch. The dsh.plugin.json in the repository is only supplementary metadata with a local schema, and the fixed DSH commit will not read this file. The prerequisites are Node.js ^22.19.0 || >=24.0.0, and DSH built from the above-tested commit. package.json lists @deepseek-ai/cordis 4.0.1 as a peer dependency, and has a runtime dependency on @deepseek-ai/schemastery 3.18.1.

The combination smoke test did not run a complete DSH turn with dependent models: the fixed shallow clone did not install workspace dependencies, nor did it have API credentials. What has been covered is the real Cordis runtime, and the parsing/applying semantics of the official bundle patch.

Installation and Activation

The installation command given on the community directory page can be run in the DeepSeek Harness terminal:

dsh plugin add github:030611/qiushi-dsh-evidence-audit

For reproducible installations, the directory page recommends appending the commit hash to the repository:

dsh plugin add github:030611/qiushi-dsh-evidence-audit#commit

Replace #commit with the actual commit hash. The plugin runs with the permissions of the current dsh process, and may execute code during installation. You should check the source code repository and license before installing.

The repository README also provides the method of installing from npm to a specified profile (package name qiushi-dsh-evidence-audit, current version 0.1.0):

dsh plugin --profile <profile> add qiushi-dsh-evidence-audit
dsh --profile <profile> --dump-config

Replace <profile> with the actual profile name, such as web in the README example. The configuration output should include an entry with id qiushi-evidence-audit and name qiushi-dsh-evidence-audit. If running from the DSH source code directory, replace dsh with pnpm dsh of that checkout according to the official documentation.

Uninstallation:

dsh plugin --profile <profile> remove qiushi-dsh-evidence-audit

Typical Usage

After installing and confirming that the above entry exists in the dump-config output, the plugin will start observing real-time publishing after being mounted. Seed/replay events that DSH intentionally does not emit to session/event during the construction phase will not be backfilled.

The default receipt path is shown in the previous section. To change the output location, the override value must be an absolute path. Subsequent profile patches will replace the entire config line, so you must retain the name and provide the full configuration. The example from the README is:

- id: qiushi-evidence-audit
  name: qiushi-dsh-evidence-audit
  config:
    outputPath: 'D:\private-audit\evidence-receipts.jsonl'

The operator is responsible for the custom target: the plugin will not modify parent directory permissions, nor handle link security. It should be placed in a private directory where other users cannot write. Each process/profile should use an independent file, and do not have two dsh instances appending to the same chain.

When reading the file, note:
1. Use sequence and previousRecordHash to check the order, do not use the line number directly as “the number of tool calls”.
2. The same logical tool result may correspond to one tool-result and one session-event, which are two observations, not two executions.
3. Tool names and event types are readable; session IDs, parameters and results only have hashes.
4. If startup fails, hashes do not match, or there is a trailing half-line, it means the existing file is already incomplete or tampered with. Stop appending first and investigate the file, rather than manually adding a line.

Applicable Scenarios and Notes

It is suitable for developers and operations personnel who are already running DeepSeek Harness locally and need to retrospectively check “what the observer saw”: for example, comparing tool call sequences, confirming whether log files have had their prefixes rewritten or their trailing half-lines truncated. It is not suitable as final evidence for compliance audits, proof of authorship, or a voucher that “the command was indeed executed successfully”.

Before using it, it is recommended to accept these limitations:
- The plugin runs with the same permissions as the current dsh process. Check the GitHub source code and MIT license before installing; fix the commit for reproducible installations.
- Receipts are pseudonymous data, do not post them to public Issues. Low-entropy values may still be subject to offline hash collisions.
- POSIX 0700/0600 cannot express complete Windows ACLs, so sensitive deployments require separate ACL verification.
- Startup verification cost is linearly related to the size of the existing file, and synchronous writeSync will add latency to event publishers.
- The community plugin repository is not an official app store; the compatibility statement of this plugin is only pinned to the aforementioned DSH commit, and you should re-verify after upgrading Harness.

Summary

qiushi-dsh-evidence-audit separates “leaving traces” and “not storing plaintext”: it listens to tools/result and session/event, writes them into a locally verifiable hash chain JSONL, and does not modify agent behavior. It can detect tampered preserved records, deleted prefixes and trailing half-lines, but cannot prove the authenticity of results, nor can it block full-file deletion or rebuilt chains after recalculating hashes.

Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/qiushi-dsh-evidence-audit/

GitHub: https://github.com/030611/qiushi-dsh-evidence-audit

npm: https://www.npmjs.com/package/qiushi-dsh-evidence-audit