Introduction

DeepSeek Harness (DSH) turns agent workflows and capabilities into pluggable components. AI coding agents invoke tools such as shell commands and file read/writes when executing tasks. If only “do not perform certain operations” is written into the prompt, or only simple text filtering is performed, there is still a lack of an auditable policy check before execution.

dsh-write-gate addresses this problem: operators describe policies using commitments, and the plugin checks these commitments before the tool invocation executes to decide whether to allow that specific tool invocation.

What is this

dsh-write-gate is a DSH plugin maintained by couldbeme, with the repository at couldbeme/dsh-write-gate, licensed under MIT, and requiring Node.js >=20.

It provides a commitment write-gate tailored for AI coding agents, with a core capability being a two-tier (deterministic + LLM judge) pre-execution policy:

  • Operators write commitments.
  • Before the tool call executes, the plugin checks these commitments.
  • Structural constraints go through deterministic checks.
  • Semantic constraints go through the LLM judge.

The core module is dsh-write-gate/core, positioned as an engine-agnostic core; the repository provides a DeepSeek Harness (dsh) adapter. The documentation also mentions that a Claude Code adapter on the same core is a planned capability.

Two-tier Checks

dsh-write-gate’s checks are divided into two layers.

  1. Tier 1 is deterministic structural checks. It uses path globs, command regexes, and scope filters, mounted on ctx.tools.guard(). It is suitable for constraints that can be clearly expressed, such as limiting certain types of shell commands or limiting the range of file paths.

  2. Tier 2 is the semantic LLM judge. It judges natural language statements within commitments, mounted on the tools/pre-execute waterfall. It is suitable for constraints where structural rules cannot fully determine the outcome, such as “do not modify files unrelated to the current task”.

Intercepted calls generate a write-gate/contradiction event and append JSONL to the contradictions log. The log explains which commitment triggered the block and why.

Commitment File

Operators define policies through a commitments file. The file can set default behavior or define commitments one by one. Below is a structural example:

defaults:
  failMode: closed
  judgeBudgetPerStep: <judgeBudgetPerStep>

commitments:
  - id: <commitment-id>
    statement: "<operator-authored commitment>"
    match:
      kinds: ["<kind>"]
      commands: ["<command-regex>"]

  - id: <semantic-commitment-id>
    statement: "<operator-authored commitment>"
    severity: <severity>
    semantic: true
    match:
      kinds: ["<kind>"]

Field meanings are as follows:

  • defaults.failMode: Controls the default behavior when the judge is unavailable. The documentation example uses closed.
  • defaults.judgeBudgetPerStep: Controls the judge budget per step.
  • id: The commitment identifier.
  • statement: The natural language constraint written by the operator.
  • match.kinds: The scope filter.
  • match.commands: The structural evidence.
  • severity: The level of the commitment.
  • semantic: true: Indicates that this commitment requires processing by the Tier 2 judge.

Several behaviors should be noted:

  • Non-semantic commitments that only have scope but no evidence will trigger on all in-scope actions.
  • Non-semantic commitments that have neither scope nor evidence will be rejected as “unenforceable” upon loading.
  • Command regexes are case-insensitive by default.
  • Command patterns are executed in a synchronous guard; overly complex or potentially backtracking regexes can block the tool pipeline. While commitments are written by operators, they should still be kept as simple as possible.
  • When the commitments file is missing or invalid, the plugin will fail loudly (loud mount failure), causing the deployment to fail, rather than mounting a gate that enforces no policy.

Installation and Enablement

First, install the npm package:

npm install dsh-write-gate

This command installs the library and the DSH plugin entry point. The core entry point is dsh-write-gate/core, and the DSH entry point is the package root entry.

The repository lists the following peer dependencies:

@deepseek-ai/cordis >=4.0.1 <5
@deepseek-ai/dsh-agent >=0.1.0-rc.5 <0.2.0
@deepseek-ai/dsh-llm >=0.1.0-rc.5 <0.2.0
@deepseek-ai/dsh-tools >=0.1.0-rc.5 <0.2.0

Before using it in a DSH application, you need to prepare a valid commitments file and mount the plugin to the target DSH process. If the commitments file is missing or invalid, the mount will fail instead of proceeding silently.

Standalone CLI Check

dsh-write-gate check allows checking without starting the harness, making it suitable for CI, pre-commit hooks, or manual verification:

dsh-write-gate check --commitments <file> --tool <name> [--path <p> ...] [--command <c>] [--explain] [--json]

Help commands are as follows:

dsh-write-gate --help
dsh-write-gate -h
dsh-write-gate check --help

The v0 form of the CLI only performs Tier 1 structural checks and does not have a --judge flag. For commitments with semantic: true that cannot be determined by structural checks, it will go to “no judge configured” and then handle it according to the failMode in the commitments file.

When failMode is the default closed, such escalating semantic commitments will block in the CLI. If a judge is configured on the DSH plugin side, the plugin side does not have this limitation of CLI v0.

If you need to run the CLI from source, you can install dependencies and build according to the repository instructions:

pnpm install && pnpm build && node dist/cli/index.js --help

Local Validation

The repository provides the following commands for testing, type checking, and demos:

pnpm install && pnpm test
pnpm typecheck
pnpm demo

If you want to run the judge evaluation script yourself, you can use:

pnpm build && node scripts/judge-eval.mjs --url <openai-compatible-endpoint> --model <model>

This command requires an OpenAI-compatible endpoint and model to evaluate the judge’s performance.

Key Design Orientations

Several key behaviors of dsh-write-gate are:

  • Fail-closed default: When the judge is unreachable, times out, or goes over budget, block-severity commitments will block execution.
  • Bounded judge cost: Uses per-step budgets, verdict memoization, and timeout-as-unavailable to limit the cost of the judge.
  • Prompt-injection stance: Action content enters the judge prompt in a fenced data format and only accepts a strict JSON verdict or ABSTAIN.
  • Loud mount failure: When the commitments file is missing or invalid, deployment fails instead of mounting a gate that guards nothing.

Applicable Scenarios and Notes

Suitable for the following scenarios:

  • Adding pre-execution policies to tools like shell and file writes in DSH.
  • Using the CLI in CI or pre-commit hooks for structural checks.
  • Needing to record which commitments were triggered and why.

Points to note before using:

  • The plugin runs with the permissions of the current DSH process. The scope of tool calls it can influence is constrained by the permissions of that DSH process.
  • Before installation, you should check the source code, commitment examples, and license.
  • Policies are written by operators. Incorrect regexes, overly broad scopes, or overly strict failMode can affect normal tool calls.
  • CLI v0 has no judge capability. Semantic commitments are handled according to failMode in the CLI; if semantic judgment is needed, a judge must be configured on the DSH plugin side.
  • The Claude Code adapter is a planned capability, not a currently delivered feature.

Links

  • GitHub: https://github.com/couldbeme/dsh-write-gate
  • Community Directory: https://www.skillhub.cn/plugins/couldbeme/dsh-write-gate

The community directory page here is an independent site and does not represent the official app store of DeepSeek or Huanshan.