The official sandbox of DeepSeek Harness (DSH) typically only offers two policy tiers: “whole-workspace writable” and “fully read-only.” This makes it difficult for developers to allow the model to develop normally while finely protecting specific paths inside the workspace, such as the .git directory, from accidental modification. The dsh-write-protect plugin takes over the sandbox policy, allowing read-only protection for specified paths inside the workspace under the workspace-write mode, while also supporting additional writable root directories and session-level grants.

The plugin is maintained by azazo1 and released under the open-source MIT license. It fills a gap in DSH for path-level permission control, making it suitable for scenarios that require fine-grained management of the model’s file write behavior.

Core Capabilities

The plugin intercepts and restricts the following behaviors:

  1. Tool interception: Intercepts writes by the write and edit tools to protected paths.
  2. Command sandbox: On Linux / macOS, blocks command sandbox (bwrap / Landlock / Seatbelt) access to protected paths.
  3. External directory allowlisting: In workspace-write mode, allows writing to certain external directories without enabling danger-full-access.
  4. Rules file: Supports placing a read-only rules file in the workspace root (default name .readonly), with the same semantics as plugin-page configuration.
  5. Session grants: The model can request temporary write permission for the current session. The permission exists only in the current session memory and is not written to configuration files.

Installation

Install into the web profile on the web client:

dsh plugin --profile web add azazo1/dsh-write-protect

Install a fixed version:

dsh plugin --profile web add azazo1/dsh-write-protect#v0.2.0

After installation, restart the application or refresh the window to apply changes. This plugin requires a DSH engine version of at least 0.2.0-rc.1.

Configure Protected Paths

Protected paths support wildcard and anchoring rules with gitignore-like semantics to define which paths are read-only.

  • Entries not containing / (e.g., .git, vendor): match at any level inside the workspace.
  • Entries starting with / (e.g., /.git, dist/a.txt): are anchored to the workspace root.
  • Entries starting with //: represent absolute file-system paths.
  • Trailing /: matches directories only.

Set readOnlyPaths in the plugin-page configuration card or deployment-level patch. For example, protect .git and all log files:

.git
*.log

If a specific file needs to be excluded (such as secrets/example.pem in the example configuration), use exclusion rules starting with !, with the last matching rule taking effect.

Configure Additional Writable Roots

Additional writable roots allow the model to write to directories outside the workspace in workspace-write mode without opening up the entire sandbox.

One literal path per line. The following expansions are supported:

  • ~ / ~/...: expands to the current user’s home directory.
  • $NAME / ${NAME}: expands to an environment variable.
  • // prefix: represents an absolute file-system path.
  • Relative paths: supports paths relative to the current session workspace, including ...

Configure writablePaths in the plugin page. For example, allow writing to a shared cache directory:

../shared-scratch
~/scratch
$HOME/scratch
/tmp/dsh-extra

Note: paths inside the workspace are ignored and will raise a warning. The file-system root (/) is rejected.

Workspace Rules File

A rules file with the same semantics as protected paths can be placed in the workspace root (default .readonly). The plugin reads the file line by line and appends the entries to the protected paths.

Example content:

secrets/
/vendor
!vendor/public/**
**
  • This file itself is the only hard protection; no grant can override it.
  • Only the copy at the workspace root is recognized, and each session reads its own copy.
  • Entries outside the workspace, symbolic links, and oversized entries are rejected.

Session-Level Write Grants

When a task repeatedly needs to write to the same protected area, the model can call a tool to request a write grant for the current session.

Request tool: request_writable_path
Parameters:
* path: the path to request (supports ~, $VAR, //, and relative paths including ..).
* justification: the reason for the request.

Grant mechanism:
* After approval, the path (and its descendants) can be accessed by the write/edit tools and command sandbox during the current session.
* Grants exist only in the current session memory, are not written to configuration files, and are limited by maxGrants (default 8).
* Approved paths are visible in the “Write Permissions” tab of the session area and can be manually revoked.

Known Limitations

  1. Windows platform: Bash or pwsh on Windows cannot block writes to .git, and additional writable roots cannot be obtained. Reads are not affected.
  2. Engine version: DSH engine @deepseek-ai/dsh-* must be version 0.2.0-rc.1 or higher.
  3. Danger mode: In danger-full-access mode, this plugin does not intervene.

Ecosystem Information

  • Plugin directory: https://www.skillhub.cn/plugins/azazo1/dsh-write-protect
  • Source code address: https://github.com/azazo1/dsh-write-protect