DSH (DeepSeek Harness) allows agents to execute Shell commands in a sandbox environment. Traditional security policies often judge danger based on command names (such as rm or cat). This approach can easily lead to false positives, or block seemingly harmless commands simply because of their names. The dsh-allow plugin changes this logic. It analyzes the filesystem paths and operation capabilities that a command actually needs, and uses that information to decide whether to grant permissions.
What It Is¶
dsh-allow is a filesystem permission-layer plugin for DSH, maintained by developer DWJZ. Its core purpose is to shift permission control from “by command name” to “by path and capability.”
The plugin intervenes at the tools/pre-execute hook, analyzes the filesystem effects of a command, and generates a Seatbelt configuration file based on predefined rules. This means that child processes inside the sandbox, inline code not explicitly shown in the command line, and programs launched by the command are all forced to comply with these permission rules.
Core Features¶
- Path-level permission control: supports fine-grained control over specific paths with five capabilities:
read(read/list),write(modify),create(create),delete(delete), andexecute(execute). - Policy modes: supports three policies:
deny(deny),allow once(allow once), andalways allow(always allow). - Tool operation rules: defines rules for management tools that request broader process permissions (such as
plugin_manager). - Seatbelt enforcement: compiles policies into macOS Seatbelt configuration files and enforces them at the sandbox entry point.
- Approval interface: provides an Approvals Tab for manual approval.
Usage Examples¶
Permissions are granted based on paths and operation types, rather than command names. The following are typical decision logic examples:
| Command Operation | Result | Description |
|---|---|---|
cat README.md |
allow | Reads a file inside the workspace |
cat ~/.ssh/id_ed25519 |
denied | User data is isolated and not readable |
echo x > out.md |
allow | Creates a file inside the workspace |
rm -rf build |
prompt | Delete operations inside the workspace require approval |
gh pr list |
prompt | Executes a binary that has not been authorized in the rules |
echo x > ~/.dsh/dsh-allow.json |
denied | The permission storage file is hard-protected and not writable |
Configuration and Notes¶
- Permission storage protection: The permission storage file (usually located at
$DSH_HOME/dsh-allow.json) and audit logs are “hard-protected.” Neither user rules nor agents can modify these files through file tools. - Workspace isolation: The plugin does not read
.dsh-allow.jsoninside the workspace, preventing repository code from elevating its own permissions. - System path protection: Platform-protected paths (such as
/System,/bin,/dev, etc.) reject all write operations (write,create,delete), regardless of how user rules are configured. - License: MIT License.
Currently, no official installation command is provided. It can be obtained from the SkillHub directory or the GitHub repository.
Short Conclusion¶
By building security policies on filesystem paths and operation capabilities, dsh-allow replaces the coarse command-name filtering mechanism. Combined with Seatbelt enforcement, it provides DSH agents with more reliable sandbox isolation.
