dsh-fs-deny-policy

DeepSeek Harness sandboxes can block the model from writing, yet every sandbox mode still permits reading. That means a directory like ~/.ssh, a license folder, or any other sensitive path left in the working area is fully exposed to reads, searches, and even shell-command snooping. dsh-fs-deny-policy closes that gap: you list a handful of deny roots in your profile configuration, and from then on every tool call—file reads, writes, glob/grep searches, bash or PowerShell commands—is denied the moment its resolved path lands inside one of those roots. The model also receives the list at the start of the session, so it stops burning turns bumping into invisible walls.

Under the hood the plugin hooks into the pre-execute stage of every tool call. It extracts the paths a call is about to touch (file_path for file tools, the search root for glob/grep, anything path-shaped inside shell command text), resolves them against the session working directory, follows symlinks, and normalises Windows casing differences. It can fence reads, searches, writes, and shell commands independently, and you can loosen or tighten each category with fenceReads, fenceShell, and fenceContentSearch. One caveat: the shell check inspects command text for path-like tokens rather than executing the command, so indirections such as variable expansion, command substitution, or redirections can slip past. Treat it as a net, not a wall, and pair it with the sandbox rather than replacing it.

It fits teams and individual developers who share a working directory or run CI jobs where the model must stay out of specific folders. If you only need write protection, turn off the read-side fence. If you need a hard guarantee, layer it on top of the sandbox as a second line of defence.