Back to home@SLAPaper

dsh-self-checking-profile

A drop-in dsh web profile that adds the **Self Checking** sandbox mode to DeepSeek Harness (dsh)

Stars
1
Language
JavaScript
Created
Aug 13, 2026
Updated
Aug 18, 2026

Introduction

dsh Self Checking

Self Checking option in the input permission picker

中文 | English

This repository ships Self Checking for DeepSeek Harness / dsh through two installable routes:

  • Plugin route (plugin/) — one normal dsh bundle package, dsh-self-checking, installed with dsh plugin add.
  • Legacy profile route (legacy/) — a reproducible fork layer over the upstream @deepseek-ai packages, installed as a standalone profile.

Both routes expose the same permission preset (🛡️🔍 Self Checking in the web picker, /permission self-checking in a session) and the same model-facing behavior: commands and file operations run under workspace-write first; an access outside the workspace is intercepted once; re-running the exact same command/operation executes it with full access.

Quick install

Plugin route

# from this checkout
./install-plugin.sh            # defaults to the `web` profile
# or explicitly:
./install-plugin.sh -p web -h ~/.dsh
powershell -ExecutionPolicy Bypass -File install-plugin.ps1

Then start dsh and select 🛡️🔍 Self Checking in the permission picker.

The package is not published to npm yet, so install-plugin.* installs the local plugin/ directory. The published command will become: dsh plugin --profile web add dsh-self-checking.

Legacy profile/fork route

# from this checkout
./install-legacy.sh                 # profile name: self-checking
npx @deepseek-ai/dsh --profile self-checking
powershell -ExecutionPolicy Bypass -File install-legacy.ps1

See legacy/README.md for the full fork-rebuild, patch-generation, and upstream-merge workflow.

How the two routes differ

Plugin route (plugin/)Legacy profile route (legacy/)
Install unitOne bundle package (dsh-self-checking) added to an existing profileA complete profile + 12 shadowing fork packages under node_modules/@deepseek-ai
How Self Checking worksPreset reuses sandbox workspace-write; a host plugin subclasses the upstream shell and fs services and adds the intercept gateAdds a real self-checking sandbox mode to SANDBOX_MODES / WIDER_MODES, implemented inside forked executors and fs fence
Upstream packagesUsed as-is through peer dependencies; the plugin imports upstream service classesVendored byte-for-byte under upstream/, forked in profile/forks/, reproducible via patches/*.json
Install UXdsh plugin --profile web add dsh-self-checking (currently local file: via install-plugin.*)install-legacy.* copies a profile and assembles the fork layer
Picker icon🛡️🔍 emoji embedded in the preset nameDedicated SVG glyph forked into dsh-client-ui-conversation
sandbox_permissions enumworkspace-write, danger-full-access only; Self Checking is a preset, not a modeworkspace-write, self-checking, danger-full-access
Session log sandbox/modeworkspace-write while the preset is activeself-checking
Degradation if the layer is missingFails closed: the preset degrades to plain workspace-write + askFails loud at profile load / execution
Baseline upgradeBump package peer ranges and re-run the plugin test suite; adaptation points are the upstream service classesThree-way merge of upstream/, regenerate patches, byte-for-byte rebuild

Model-facing semantics are intentionally the same: the intercepted/failed markers, the one-time exact re-run unlock, the defensive fs failure hint, and the explicit sandbox_permissions + justification approval channel all match.

Repository layout

├── plugin/                      dsh-self-checking bundle package (new route)
│   ├── lib/                     host plugin + shell/fs service subclasses
│   ├── cordis.patch.yml         disables native service rows, adds the preset
│   ├── scripts/                 dev-profile installer and installed verifier
│   └── tests/                   unit, Cordis, native tool-layer, live runner
├── legacy/                      original fork/profile route
│   ├── profile/forks/           12 shadowing fork packages
│   ├── upstream/                byte-exact upstream baseline (0.1.0-rc.7)
│   ├── patches/                 anchored patch manifests + review diffs
│   ├── tools/                   snapshot / merge / gen-patches / rebuild / release
│   ├── tests/                   legacy regression + ACL probes
│   ├── install.sh / install.ps1
│   ├── verify.mjs
│   └── docs/                    picker screenshot used by the legacy README
├── install-plugin.sh / .ps1     plugin-route installer (local file package)
├── install-legacy.sh / .ps1     wrappers around legacy/install.*
├── docs/self-checking-routes.md delivery decision record
├── CHANGELOG.md
└── LICENSE

Which route should I use?

  • Use the plugin route for everyday installation and testing.
  • Use the legacy route when you need the byte-reproducible fork layer, upstream-baseline archaeology, or the exact self-checking sandbox mode in the session log and escalation vocabulary.

Requirements

  • dsh 0.1.0-rc.7 (run any dsh profile once first so ~/.dsh/profiles/node_modules exists);
  • Windows, macOS, or Linux. The plugin route's real-runner test coverage is currently Windows-only; the legacy route is platform-independent.

Development

# Plugin route
cd plugin
npm test
npm run test:live    # real Windows pwsh + windows-acl runner

# Legacy route
node legacy/tests/verify-self-checking.mjs
node legacy/tests/verify-acl-probe.mjs    # real Windows ACL probe

See plugin/README.md, legacy/README.md, and docs/self-checking-routes.md.