This is important context for any report, so it comes first.

The multi-folder workspace feature deliberately widens the agent's write surface. In workspace-write mode, a session that belongs to a multi-folder workspace can write to every member folder of that workspace, not only to its own working directory. Achieving that required patching DSH's sandbox components:

Properties that are preserved:

• Paths outside the member set are still denied, with the same FS_SANDBOX_DENIED error and the same [sandbox: …] escalation path.
• read-only and danger-full-access semantics are unchanged.
• Members are canonicalized with realpath and re-resolved on each check, keeping the upstream stance on symlink drift.
• No member may be an ancestor or descendant of another member, in the same workspace or across workspaces, so a session's working directory never resolves to two workspaces.
• Membership changes are auditable: each add/remove is appended as a workspace/membership session event and projected into the model's context, so the trail can be replayed.
• Removing a member revokes its write access immediately; the roots provider is consulted on every policy resolution rather than cached in process state.

If you install this, you are accepting a wider blast radius in exchange for cross-folder work. That trade-off is the design, not a bug.

Please do not open a public issue for a security problem.

Use GitHub's private vulnerability reporting on this repository: Security → Report a vulnerability. If that is unavailable to you, open a normal issue that says only "security report, please provide a contact channel" with no details, and a private channel will be arranged.

Useful things to include:

• Which baseline (fork/fork.json baseVersion) and which plugin version.
• Platform and sandbox dialect (macOS Seatbelt, Linux bwrap or Landlock, Windows ACL).
• The workspace member layout that triggers it.
• Whether stock DSH is also affected (see below).

Expect an acknowledgement within a few days. This is a personal side project, not a staffed product, so please size your expectations accordingly — but security reports get priority over everything else here.

In scope — anything where the patch set or the plugin makes DSH weaker than it is upstream:

• Writing outside the workspace member set in workspace-write mode.
• A session inheriting write access to a folder that is no longer a member.
• Bypassing the nesting or ownership rules to make one path belong to two workspaces.
• Path traversal or symlink tricks in the plugin's directory browsing or in the member RPCs.
• Sandbox escape specific to the multi-root grant on any platform.
• Credential or path leakage introduced by the membership events or the model-context projection.

Out of scope:

• Vulnerabilities in unpatched upstream DSH — report those to deepseek-ai/deepseek-harness instead. If a patched package amplifies an upstream issue, do report it here.
• The documented, intentional widening of the write surface described above.
• danger-full-access behaving as its name says.
• Issues that require the operator to already have write access to DSH_HOME or to the deployment tree.

Only the current baseline receives fixes: the patch set is built against one exact upstream release at a time (see fork/fork.json). Older baselines are not maintained — the fix path for an old baseline is to rebase onto the current one.