Preface¶
DeepSeek Harness (dsh) is an open-source agent runtime developed by DeepSeek AI, with the architectural slogan “Everything is a plugin”. Models, tools, sessions, and interfaces can all be split into independent modules, which are assembled into a profile by Cordis. This structure facilitates extensibility but also brings a concrete problem: after an agent completes a round, the conversation often contains statements like “the test has been run” or “the check passed”, but there is no standalone executable summary that can be opened locally without the full conversation transcript.
dsh-verification-receipt does something quite restrained. It does not prove that the test actually ran, nor does it endorse the correctness of the code. Every time a durable turn/end event arrives, it only appends the recorded tool counts from that round and lexically identified “verification-like” signals to a local JSONL file. The repository README summarizes this into an even smaller, more easily verifiable question: What execution signals that look like verification operations did DSH record in this round?
Based on cross-verified information from the directory page and the GitHub repository, this article introduces what this plugin is, what is included in the receipt, how to install it, and what it explicitly does not do.
What It Is¶
dsh-verification-receipt is a session and message plugin maintained by GitHub user 030611, with the current version 0.1.0 and MIT license, primarily written in TypeScript. It was included in the community directory page on 2026-08-14; as of 2026-08-18, both the directory page and the GitHub repository have 5 stars. It can be installed via the npm package with the same name dsh-verification-receipt.
It is a small, passive Profile Bundle: package.json declares dsh.bundle.patch, and cordis.patch.yml inserts a regular observation plugin with the id verification-receipt. It can be used by any DSH output surface that provides the core Session service. The plugin temporarily reads tool names, original parameters, and result statuses from existing durable events to calculate summaries, but does not retain these inputs when writing to disk. It does not append Session events, register tools, add prompt segments, inject context, initiate model calls, or alter model history.
Two points need to be clarified first. First, the community plugin directory deepseek-harness-plugin.com is an independent site for retrieving and installing community plugins, and has no official affiliation with DeepSeek / 幻方. Do not treat it as an official app store. Second, the repository itself clearly states: this plugin is community-maintained and not an official DeepSeek project. The same maintainer has also listed several related trust-layer plugins, namely Telemetry Redactor, Evidence Audit, and Context Provenance; dsh-verification-receipt intentionally does not act as an evidence-audit ledger, keeping each line independent, without introducing hash chains, artifact capture, claim-evidence association, or protocol proof.
What Is Included in the Receipt¶
The default output file is:
$DSH_HOME/verification-receipts/v1/receipts.jsonl
If DSH_HOME is not set, the path resolves to ~/.dsh. You can override it with an absolute path in the profile’s cordis.patch.yml:
- id: verification-receipt
config:
outputPath: /absolute/private/path/receipts.jsonl
The repository README provides the structure for each line (field values are documentation examples, not from a real user session):
{
"schemaVersion": 1,
"kind": "dsh-verification-receipt",
"sessionIdHash": "sha256:…",
"turn": 3,
"turnEndSeq": 42,
"endedAt": 1786630000000,
"outcome": "completed",
"tools": {
"calls": 4,
"succeeded": 3,
"failed": 1,
"unresolved": 0,
"topLevel": 2,
"nested": 2
},
"verificationSignals": [
{
"source": "command",
"category": "test",
"status": "failed"
}
],
"claim": "execution-trace-only",
"receiptHash": "sha256:…"
}
Several fields should be understood literally as per the documentation:
1. claim is fixed as execution-trace-only. The receipt only indicates that DSH recorded tool calls and lexically heuristically identified possible verification signals.
2. tools is a count, not the original command text. It counts the number of calls, successes, failures, unresolved calls, as well as top-level and nested calls.
3. verificationSignals only retains source, coarse-grained category, and the observed status.
4. sessionIdHash is a deterministic, key-free SHA-256 with domain separation, used to group receipts from the same Session without saving the original session id. The repository explicitly states this is pseudonymization, not anonymization: if the Session id is predictable or has low entropy, an observer can offline guess candidate values and recalculate the hash.
5. receiptHash is the SHA-256 calculated from all preceding receipt fields in the order of output. Neither hash uses a key, and both can be recalculated. Anyone who can edit a line can also recalculate its hash. Independent lines cannot expose deletion, insertion, rearrangement, truncation, rollback, or replacement. It is not a signature, trusted timestamp, hash chain, commitment, or tamper-proof log.
The written receipts do not include: tool parameters or call ids, tool result bodies or error messages, assistant or user message bodies, original session id, working directory, provider name, or model name.
How Heuristic Signals Are Determined¶
Heuristic signals are generated in two cases:
1. The tool name resembles work related to test, typecheck, lint, build, check, verify, or validate.
2. The in-memory command or cmd parameter of a shell-like tool resembles the aforementioned work.
Classification only uses lexical matching, without parsing shell semantics, expanding aliases, or executing commands. DSH-native tool errors and identifiable non-zero shell exit codes count as failures. Background commands remain unresolved because subsequent job results may occur outside this turn. Even with status: succeeded, it only means no recognized failure markers were observed for the call; it does not mean the test passed, or even that the test actually ran.
The supported boundaries listed in the repository can be summarized as follows:
1. The string command / cmd in JSON string or object parameters will be checked, but only for recognized shell-like tool names.
2. Case, quotes, and visible bash -lc / pwsh -Command wrappers can be lexically matched, provided the classification keyword is still visible in the string.
3. Array commands, argv, nested command objects, and custom shell tool names are not supported and will not generate signals.
4. Aliases or wrappers without visible classification keywords will be missed.
5. Quoted text such as echo "do not run tests" will be matched lexically, so false positives are expected.
The documentation requires that each match be called a “heuristic signal”, not “the test has been run”, and it should not be treated as proof or a quality gate.
Installation and Activation¶
The installation command provided on the directory page is as follows, run it in the DeepSeek Harness terminal. The dsh CLI will resolve the plugin from GitHub and install it to the current configuration:
dsh plugin add github:030611/dsh-verification-receipt
For reproducible installations, the directory page recommends pinning the commit hash:
dsh plugin add github:030611/dsh-verification-receipt#commit
Replace commit above with the actual commit hash. The repository README additionally provides the method to install the published npm package per profile, suitable for scenarios where receipts need to be generated for a specific profile:
dsh plugin --profile web add dsh-verification-receipt
dsh --profile web --dump-config
If other profiles (such as headless) also need receipts, repeat the first command with the corresponding profile name. For local development, clone the repository, run pnpm install --frozen-lockfile && pnpm run check, then pass the checkout path instead of the package name to dsh plugin ... add.
The Node engine declared in package.json is ^22.19.0 || >=24.0.0. The compatibility evidence takes the DeepSeek Harness commit 47f943859bef60e4160492346772ded9b24f765a as the audit baseline; the manifest of this commit declares @deepseek-ai/dsh-session 0.1.0-rc.5, Cordis 4.0.1, and Schemastery 3.18.1. The peer range starts from these versions and ends before the next semver major version of dsh-session stable version 0.1.0 or Cordis / Schemastery. Release checks also cover the currently installable dsh-session 0.1.0-rc.6. Versions within the range but not named are only expected to be compatible, not empirically verified.
Both the directory page and the repository remind users that the plugin runs with the permissions of the current dsh process, and may execute code during installation. Please check the source code repository and license before installing.
Impact on the Model Loop¶
According to the “Model Experience” description in the repository, this observation plugin tries not to touch the main agent path:
1. Does not increase token costs.
2. Does not register new tools for the model.
3. Does not modify Session logs, only reads existing events.
4. Does not alter prompts or context.
5. The listener synchronously scans completed turns and queues local file I/O; the turn path does not wait for disk operations.
It is suitable for scenarios where you want to keep a lightweight local execution trace without wanting the plugin to alter conversations or tool surfaces. For example, troubleshooting how many tools were called in a round, whether there were calls with test/lint/build in their names or commands, and whether these calls were recorded by DSH as successful, failed, or unresolved. It is not suitable for use as a release gate, compliance evidence, or adversarial tamper protection.
Applicable Scenarios and Notes¶
Scenarios where it is suitable to use can be summarized as: you need a privacy-minimized per-turn summary; you can accept lexical heuristic misses and false positives; the output file is only readable and writable by the user running DSH locally. SECURITY.md requires that the JSONL not be placed in workspaces visible to the agent, shared directories, synchronized public folders, or untrusted mount points. When creating directories and files on supported POSIX file systems, the plugin requests 0700 / 0600, but will not tighten existing permissions. Windows may ignore POSIX modes and will follow pre-existing symbolic links. Please configure a trusted, private, non-symbolic link path.
Known limitations also come from the repository, and do not treat them as promises that they will be automatically fixed in the future when writing:
1. Receipts only cover events observed during the plugin’s runtime; it will not backfill constructed seed history or turns that ended during plugin uninstallation.
2. Process crashes may lose receipts still in the queue, because turn/end does not synchronously wait for this optional local sink.
3. Each line is independent of others, and cannot detect deletion, rearrangement, truncation, or rollback.
4. The receipt status repeats the tool results recorded by DSH and identifiable shell markers, and does not independently execute or verify any content.
5. There is no cross-process lock. When two DSH processes write to the same file, the line order and line boundary integrity are not guaranteed; each process should use an independent file. Crashes may leave incomplete trailing lines, and readers must reject or isolate them.
6. In-process write queues are ordered but unbounded; slow or stuck file systems will continuously increase memory usage.
7. The file has no built-in rotation, retention policy, encryption, signature, or recovery mechanism.
This is a 0.x pre-release plugin, and security fixes only target the latest commit. DeepSeek Harness itself is still in developer preview, and the official repository notes that there will be breaking changes. Before installing community plugins, in addition to checking the license, you should also verify whether the current dsh version falls within the peer range declared by the package.
Summary¶
dsh-verification-receipt leaves a very thin local receipt for each round of DeepSeek Harness: tool counts plus lexically identified verification signals. It answers a very narrow question with clear boundaries — it records execution traces, but does not prove semantic correctness. If you need to know “what DSH recorded in this round”, rather than “whether what the agent said is true”, you can install it via the directory page command and check $DSH_HOME/verification-receipts/v1/receipts.jsonl.
Directory page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-verification-receipt/
GitHub: https://github.com/030611/dsh-verification-receipt