Introduction

In DeepSeek Harness (DSH), plugins can extend how agents work. For coding tasks, the risk often lies not in “whether it can execute commands,” but in the lack of clear task boundaries, approval records, and verifiable evidence when continuously modifying files, code, and running verification.

dsh-safe-workflow is an independent DSH plugin designed to make coding workflows more controlled and verifiable: it adds policy checks before the model calls tools and leaves task contracts, approvals, checkpoints, and verification records during execution.

Below is an introduction to its capabilities, local installation method, a typical usage scenario, and its limitations regarding sandboxing.

What is it

dsh-safe-workflow is a DeepSeek Harness plugin maintained by cnwutianhao under the MIT license.

Its goal is not to replace DSH’s sandbox, but to introduce more explicit constraints into DSH workflows: task contracts, path rules, approval gates, checkpoints, verification records, and best-effort file snapshots.

Core Capabilities

The plugin exposes a tool to the model: safe_workflow. It supports the following operations:

  • start: Create a task contract;
  • status: View the current active contract;
  • checkpoint: Take a snapshot of the selected workspace state;
  • restore: Restore a specific checkpoint;
  • verify: Run verification commands and record output;
  • close: Close the contract.

The plugin also installs two DSH native policy listeners:

  • tools/pre-execute: Check path rules and request approval before change-making tools are executed;
  • tools/execute: Create automatic, best-effort checkpoints before changes occur.

The plugin writes state to the .dsh-safe-workflow/ directory under the current session workspace:

.dsh-safe-workflow/
contract.json
audit.jsonl
checkpoints/

Where:

  • contract.json: Saves the active task contract and verification records;
  • audit.jsonl: Appends session, tool, and checkpoint evidence;
  • checkpoints/: Saves checkpoint manifests and copied files.

Installation and Enablement

The installation instructions provided by the plugin are for local DSH source checkout installation, using PLUGIN_DIR to point to the plugin directory; no npm registry installation command is provided.

First, complete the plugin build, then execute the following in the DSH checkout:

DSH_DIR=/path/to/deepseek-harness
PLUGIN_DIR=/path/to/dsh-safe-workflow

cd "$DSH_DIR"
pnpm dsh plugin --profile web add "$PLUGIN_DIR"

After installation, the plugin appears in the DSH plugin list and is enabled in the Web profile. You can confirm this via the DSH plugin list or configuration output.

Typical Usage

An example task can be described as follows:

Start a safe workflow titled "Fix parser regression".
Goal: fix the parser regression without changing public APIs.
Acceptance checks: run npm test and npm run typecheck.
Only allow changes under src/ and test/.
Require approval before bash, write, edit, or str_replace_editor.

Here, the task goal, acceptance commands, allowed modification paths, and tools requiring approval are all written into the contract.

Once the implementation is complete, the agent can run safe_workflow verify to perform the acceptance check; only when the acceptance passes should safe_workflow close be run to close the contract.

When a tool that modifies state is about to execute, the approval gate will explain the requested operation, allowing you to choose to approve or keep the contract unchanged.

Applicable Scenarios and Notes

It is suitable for scenarios where users wish to add explicit boundaries to DSH coding tasks: restricting paths, requiring approvals, and leaving verification and checkpoint records.

Special attention is required: It is a workflow guard, not a process sandbox. The plugin runs within the host process and possesses host process permissions. It provides policies, evidence, and best-effort file snapshots, but does not guarantee atomic rollback for arbitrary shell side effects, network operations, databases, or files not included in checkpoints.

If used in a production environment, it is recommended to:

  1. Review the plugin source code;
  2. Pin the plugin version or commit;
  3. If necessary, place .dsh-safe-workflow/ outside of sensitive repositories;
  4. Keep DSH’s normal sandbox and approval layers enabled.

References

  • Directory page: https://www.skillhub.cn/plugins/cnwutianhao/dsh-safe-workflow
  • GitHub: https://github.com/cnwutianhao/dsh-safe-workflow