【BUG REPORT】workspace-write allows recursive deletion of the entire workspace with zero confirmation

[jesusblessf6]

Summary

Under the workspace-write permission preset, an agent can recursively delete the entire workspace root (rm -rf <workspace> / shutil.rmtree(workspace_root)) with no approval prompt, no sandbox denial, and no confirmation of any kind. The project is destroyed silently; recovery depends entirely on external backups/remotes.

Reproduction

1. Start a session with the default workspace-write preset (sandbox: workspace-write, approval: ask).
2. Execute inside the workspace: rm -rf /path/to/workspace (or any Python shutil.rmtree targeting the workspace root).
3. Observed: the operation succeeds silently. No approval is requested at any point.

Root cause

The permission model authorizes by path space, not by operation semantics:

• The sandbox (dsh-sandbox-local) expresses workspace-write as a bwrap bind mount (--bind workspaceRoot workspaceRoot) / Landlock allow-list. To the kernel, recursively deleting a directory tree is just a sequence of in-range unlink() calls — indistinguishable from deleting a temp file.
• The approval: 'ask' policy only fires on out-of-policy retries (escalation requests). Deleting the workspace root is fully in-policy, so ask never triggers.
• There is no notion of "destructive in-policy operation" anywhere in the model. The default preset table (see dsh-permission-presets) contains only workspace-write and danger-full-access.

Real-world impact

This caused an actual incident: a test-cleanup bug (shutil.rmtree(os.path.dirname(db_path)) in a finally block, where dirname resolved to the project root) silently deleted an entire project — code, .git, virtualenv, docs — with zero prompts. Recovery was only possible because the repository had been pushed to GitHub beforehand.

Suggested fixes (any of these would have prevented it)

1. Minimal, near-zero false positives: block deletion operations whose target is the workspace root itself (or a path whose removal would remove it). Normal development never deletes the workspace root, so rejecting this outright is safe.
2. General: add an approval knob for destructive in-policy operations (recursive delete / directory wipe), e.g. a destructive-ops: ask option, or extend the ask policy to also match dangerous operation patterns rather than only out-of-policy retries.
3. Documentation: state explicitly in the preset description that workspace-write includes deleting any content inside the workspace, so the permission name does not understate its blast radius.

Environment

• @deepseek-ai/dsh 0.1.0-rc.6
• macOS host, sandbox-local backend

References

• Permission preset table: dsh-permission-presets — only workspace-write / danger-full-access; approval gates out-of-policy retries only.
• dsh-sandbox-local bwrapProfileArgs: workspace-write → --bind workspaceRoot workspaceRoot.

[Zenine]

Confirmed the mechanism against the code, with two corrections that matter for whoever picks this up.

The preset table and approval: 'ask' scope are as described. dsh-permission-presets ships exactly workspace-write (sandbox: workspace-write, approval: 'ask') and danger-full-access, and nothing in the model treats an in-policy destructive operation differently.

Correction — the blast radius differs by backend. sandbox-local's bwrap profile uses --bind workspaceRoot workspaceRoot, so inside the sandbox the workspace root is a mountpoint: rm -rf <workspace> destroys the contents, but removing the root directory itself returns EBUSY. The Landlock profile (readWrite.push('/tmp', workspaceRoot)) and Seatbelt have no mountpoint, so there the root goes too.

backend	result
Linux + bwrap	contents destroyed, root directory survives
Linux + Landlock	fully removed
macOS + Seatbelt	fully removed (your environment)

Same disaster either way, but "delete the workspace root" is not accurate under bwrap, and a fix that only guards the root would leave the bwrap case fully exploitable anyway.

Constraint on suggested fix #1. It cannot be implemented in ctx.fs: the FileSystem Service Definition has no delete operation at all — only resolve, stat, lstat, readText, streamText, readBytes, listDir, writeText, editText. Every deletion in the product goes through ctx.shell. So a "destructive in-policy operation" gate has to live in the shell/sandbox layer (or in a new fs operation, if deletion is ever added there), not in the filesystem fence — which also means dsh-fs-sandbox's containment logic is not where this gets solved.

[weijiafu14]

这个事故现在可以先加一道独立于主 Agent 的拒绝门。pi-approval-guardian 已经通过 pi2dsh 在真实 DSH 中验证了 allow/deny；它会把每条 bash 命令交给单独 reviewer，并且 reviewer 异常时 fail closed。

dsh plugin --profile web add pi2dsh@0.10.0
dsh plugin --profile web add pi-approval-guardian

export PI_APPROVAL_GUARDIAN_MODEL=deepseek-official/deepseek-v4-flash
export PI_APPROVAL_GUARDIAN_POLICY='禁止删除 workspace 根目录或递归清空整个项目；任何 rm -rf、shutil.rmtree、Remove-Item -Recurse 涉及 workspace root 或其全部内容时必须拒绝。'

仓库和复现说明： https://github.com/weijiafu14/pi2dsh

这不是替 DSH core 宣称问题已经修复：最稳妥的上游修复仍应当落在 shell/sandbox 执行层，做确定性的 workspace-root destructive-op guard。这个插件方案的价值是今天就能给现有安装加第二道、不同模型判定的防线，也能覆盖一部分不止 rm -rf 的变体。

[zoahdev]

Confirming the mechanism and adding the one thing that makes the fix tractable: this is the third member of the same sandbox-inconsistency family, and each has a different correct layer.

The family

• write-side ([Bug] Windows 的极简模式运行 Shell 工具时报错，str_replace_editor 工具在 Read Only 的情况下可读写工作区外文件 #2066): minimal preset's str_replace_editor dropped the permission mode on a bare fs. Fixed at the tool layer (editor enforces the policy when the mounted fs doesn't confine).
• read-side ([Bug 报告 / 设计问题] glob/grep 工具完全绕过沙箱：`path` 无任何策略约束，可读取工作区外任意文件（含隐藏文件）并注入模型上下文 #951): glob/grep never see fs/sandboxPolicy at all, so reads are documented-open but unvalidated. Fix belongs at the search tool (workspace confinement + escalation for out-of-workspace paths).
• destructive-side (this thread): the policy is path-space, not operation-space. workspace-write means "unlink/rmdir within the root", and a recursive delete is just a sequence of in-range unlinks — indistinguishable from deleting a build dir. The blast radius differs by backend exactly as @Zenine mapped (bwrap root survives as a mountpoint, landlock/Seatbelt lose the root).

Why the fix can't live in ctx.fs

Agreed with @Zenine: FileSystem has no delete operation, so this isn't a dsh-fs-sandbox containment change. Deletion is ctx.shell. The question is whether to enforce semantics at the sandbox backend (deterministic) or at the shell tool (heuristic).

Two concrete fix surfaces

1. Deterministic, backend-level: Landlock already distinguishes REMOVE_DIR from REMOVE_FILE. A profile can deny removing the workspace root directory (and, for the "recursive wipe" case, deny REMOVE_DIR on the root's immediate children) while leaving ordinary unlink of files and nested subdirs untouched. bwrap's --bind already protects the root (EBUSY); the gap is only the contents. Seatbelt would need the equivalent "deny rmdir of this exact inode" grant. This is the durable fix, but it's per-backend and touches the sandbox runner.
2. Pragmatic, shell-level: add a destructive-ops: ask knob (the reporter's #2) — the bash/pwsh pre-execute routes command patterns that recursively delete the workspace root (rm -rf <root>, shutil.rmtree(<root>), Remove-Item -Recurse <root>) through ctx.approval even when the effect is in-policy. It's a heuristic and bypassable (obfuscated commands), but it's a real second line that's shippable today without backend work.

My recommendation: ship (2) now as the user-facing stop-gap, and treat (1) as the release-train item because it needs per-backend grants + a policy-vocabulary extension (destructive-op). I can prepare a cherry-pick-ready branch for (2) — it's the same approval/escalation path bash already uses for out-of-policy effects, just keyed on a destructive-command classifier instead of path containment.

Would maintainers rather see the classifier in the shell tool or as a reusable destructive-ops service both bash and pwsh consume?