DSH (DeepSeek Harness) uses a sandbox mechanism by default. When an Agent writes outside the workspace directory, it often enters a loop of “access denied → escalated retry → manual approval.” The dsh-fs-allowlist plugin is designed to address this pain point by intercepting write operations and allowing approval-free access to configured allowlisted directories, while also providing a settings interface and automatic approval for Bash commands.

Core Features

This plugin mainly solves approval issues in two types of write scenarios:

  1. File tools (write/edit): It wraps the ctx.fs.checkedTarget sandbox interceptor. If the target path is under an allowlist root directory, the request is allowed to proceed directly without triggering the manual approval workflow.
  2. Bash commands: It uses tools/pre-execute to listen to command text, combined with the approval/request answer mechanism. If the Bash command text or escalation reason contains an allowlisted path (recursive matching is supported), the system automatically approves that execution and no longer displays an approval dialog.

Installation and Enablement

Use the official command to install the plugin into the web profile:

dsh plugin --profile web add "github:wzn16/dsh-fs-allowlist#main"

After installation, restart DSH Desktop to make it take effect. Restarting is also required after modifying source files.

Configuration and Usage

1. Manage via the Settings Interface

Configuring it through the graphical interface is recommended. In DSH Desktop, go to Settings, find “Directory Allowlist” under the “Plugins” tab, and add the directory paths that should be writable without approval.

2. Edit the Configuration File

You can also directly edit the configuration file $DSH_HOME/fs-allowlist.json. The file format is as follows:

{
  "extraWritableRoots": [
    "/Users/you/ObsidianVault"
  ],
  "bashAutoApprove": true
}
  • extraWritableRoots: Defines the allowlisted directories.
  • bashAutoApprove: Controls whether Bash commands are automatically approved. The default is true.

The configuration supports hot reloading: interface changes take effect immediately, and manual changes to the configuration file are usually detected within 3 seconds.

How It Works

Write Layer

DSH write operations are processed by default through the ctx.fs.checkedTarget interceptor mounted by dsh-fs-sandbox. This plugin mounts on top of that interceptor:
- Allowlist hit: It uses realpath (the resolved absolute path) to check whether the target is under an allowlisted root directory. If it is, the operation is allowed.
- No hit: It delegates to the original interceptor, preserving the existing deny/approval logic.

Bash Layer

Bash runs inside the Seatbelt process sandbox, and the plugin cannot extend its configuration. Therefore, it uses heuristic matching:
1. During the tools/pre-execute phase, it records the command text.
2. During the approval request phase, it parses the command text and reason, and expands ~ symbols.
3. It recursively checks whether an allowlisted path is included. If matched, it automatically replies allowed-once.

Notes

  1. License: MIT License.
  2. Bash heuristic limitation: Automatic approval depends on the command text or reason containing an allowlisted path. If neither matches, the system falls back to manual approval (this is a safety mechanism).
  3. Internal dependency risk: The plugin depends on the DSH internal ctx.fs.checkedTarget seam. If DSH is upgraded and refactors this interface, plugin behavior may degrade, appearing transparent (equivalent to being uninstalled).
  4. Security risk: Allowlisted entries mean the Agent can write without asking. Keep the list concise as much as possible.
  5. Missing configuration handling: If the configuration file is missing, empty, or invalid, the plugin behaves as if it is uninstalled and does not break existing sessions.

References