[Bug][Safety] DSH 0.2.1-rc.2: cleanup command expanded to C:/ root and deleted user files

[ZyptusOn]

TL;DR: A cleanup command intended for a project subdirectory was executed with cmd /c rd /s /q and traversed from the C:/ root. It deleted 48 user music files and much of C:/Program Files before the 120 s timeout; a sanitized excerpt is below, and the full 21 MB log/hash can be provided privately.

[Bug][Safety] DSH 0.2.1-rc.2: cleanup command expanded to C:/ root and deleted user files

Environment

• DeepSeek Harness 0.2.1-rc.2 (Windows desktop, nightly feed)
• Windows 11 Pro 10.0.26300
• PTC mode, danger-full-access, approval: never
• Shell: pwsh tool -> cmd /c

What happened

At 2026-10-21 18:11:30, a cleanup command intended to remove only:

C:/Users/<user>/Documents/AI/Moveit/pvkit/projects/v4_wall_full/out/film_blur_frames

was executed as:

$d='C:/Users/<user>/Documents/AI/Moveit/pvkit/projects/v4_wall_full/out/film_blur_frames'
if(Test-Path $d){ cmd /c "rd /s /q \"$d\"" }

Instead of removing that directory, the child process traversed from the C:/ root.
It deleted C:/CloudMusic (48 files), CloudMusic resources, and much of
C:/Program Files before the 120 s tool timeout killed it, before C:/Users was reached.

Evidence

• DSH subprocess stderr: dsh-subprocess-13316-14-0f44be01a987-stderr.log
• Size: 21,026,880 bytes
• 203,612 lines of "Access is denied"; 14 lines "being used by another process"
• Paths start at $RECYCLE.BIN, /CLOUDM1, /PROGRA1, /PROGRA~2
• Parent process: DeepSeek Harness.exe PID 13316
• SHA-256 of full log: 80EF8DB82D67357577B3FEAAF2706E2E1D66A2E05E78A07A46DFA2F75E03EE7F

I can provide the full log privately if needed; it contains local paths, so I am not
attaching all of it publicly.

Impact

• 48 music files deleted from C:/CloudMusic
• CloudMusic install resources removed (app reports resource corruption)
• Cromite, v2rayN, VPEM, MuMu VBox components partially/fully removed
• QQ was also damaged and reinstalled
• Windows core was repaired with SFC/DISM/CHKDSK; no bad sectors

What I think should change

1. Never allow shell delete commands (rd /s /q, del /s, Remove-Item -Recurse)
   to receive a root/empty/ambiguous path; resolve and validate the target first.
2. Require an explicit confirmation for destructive commands even in
   danger-full-access, or provide a workspace-only delete guard.
3. Do not execute cmd /c rd /s /q with interpolated variables; use a safe
   file API and reject paths outside the approved workspace.
4. Make command timeout kill the process tree immediately; this one ran 120 s
   and traversed multiple top-level directories.
5. Add a regression test where the target variable is empty/malformed and assert
   that no path outside the workspace is touched.

Note

I understand DSH is a developer preview and SAFETY.md warns that model-generated
commands can delete files. The issue here is not sandbox bypass: the command was
intended to be scoped to a project directory, but path/quoting expansion made it
target the C:/ root.

Minimal repro (do not run on a real C: drive)

Use a disposable VM. Set an empty or malformed $d, run the command form above,
and observe whether rd resolves outside the intended directory.

Sanitized stderr excerpt

--- first 40 lines ---
\$RECYCLE.BIN\S-1-5-18 - Access is denied.
\$RECYCLE.BIN - Access is denied.
\$WINRE_BACKUP_PARTITION.MARKER - Access is denied.
\AMTAG.BIN - Access is denied.
\appverifUI.dll - Access is denied.
\CLOUDM~1\VIPSON~1\井口裕香 - 白金ディスコ.ncm - The process cannot access the file because it is being used by another process.
\CLOUDM~1 - The process cannot access the file because it is being used by another process.
\DOCUME~1 - Access is denied.
\hiberfil.sys - The process cannot access the file because it is being used by another process.
\https_personal.sdwan.oray.com.localstorage - Access is denied.
\NATPIE~1\natpierce.dll - Access is denied.
\NATPIE~1\natpierce.exe - Access is denied.
\NATPIE~1\network.dll - Access is denied.
\NATPIE~1 - The process cannot access the file because it is being used by another process.
\pagefile.sys - The process cannot access the file because it is being used by another process.
\PerfLogs - Access is denied.
...
\PROGRA~2\ENDNOT~1\Styles\APA 6th-full name.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\APA 6th.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\APA 7th-Annotated.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\APA 7th.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\App Animal Behaviour Sci.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\App Phys Letters.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\Applied Catalysis B.ens - Access is denied.
\PROGRA~2\ENDNOT~1\Styles\Archives Gen Psych.ens - Access is denied.

[argszero]

Thank you for writing this up with the stderr excerpt — the paths in it are what made the cause findable, and I am sorry about the files.

The mechanism is quoting, and it is now measured rather than inferred. \" is a cmd.exe escape, not a PowerShell one: PowerShell escapes with a backtick, so in

cmd /c "rd /s /q \"$d\""

the double-quoted string ends at that quote. I ran the exact line under PowerShell 7.6.7 with a stand-in cmd that prints its argv instead of executing:

command	what the delete verb receives
cmd /c "rd /s /q \"$d\""	rd /s /q \ and <the path>\ as two separate arguments
cmd /c "rd /s /q \"$d`""`	rd /s /q "<the path>" as one

cmd /c joins the remaining arguments with spaces, so the delete verb is handed \ — the root of the current drive — and the path you meant becomes a second, trailing operand. Your stderr agrees independently, which is the strongest part of the report: every path in it is anchored at the drive root (\PROGRA~2, \$RECYCLE.BIN, \pagefile.sys), not at a subdirectory. Nothing in the harness looked at the target, because danger-full-access means exactly that.

On your five asks, split by who owns them.

1. Reject a root/empty/ambiguous target before running it — this is now available as a plugin (below) for the catastrophic half. Full resolution against the workspace belongs in the core.
2. Confirm destructive commands even in danger-full-access, or a workspace-only delete guard — core. The approval plane is the right place, and a plugin must not quietly narrow a mode the operator chose.
3. Do not run cmd /c rd /s /q with interpolated variables; use a file API — guidance for command authors, and the core would need to offer the file API a model can actually reach for deletes.
4. Make the timeout kill the process tree — core, and separate from this report; a timeout that ends the tool without ending the tree is its own defect.
5. A regression test with an empty or malformed target — the plugin's suite pins the measured argv above, so a change that stopped reproducing it fails rather than quietly agreeing with itself. A core test would need a Windows runner.

What now exists. @argszero/dsh-recursive-delete-guard — https://github.com/argszero/dsh-recursive-delete-guard (0.1.0, MIT, zero runtime dependencies, no build step).

npm i github:argszero/dsh-recursive-delete-guard

Mount it through its cordis.patch.yml. It reads the command before dispatch, splits it in the dialect of the shell that would actually run it, follows cmd /c and sh -c wrappers inside it, and denies the call when a recursive delete's operand is a filesystem root, a drive root, a bare drive letter, a path relative to the current drive's root, a path that normalizes to its own starting directory, or nothing at all. Your exact command is refused, and the reason names the backtick hazard. 136 tests; 30 injected mutations, all caught, with a no-mutation control required to report zero.

What it does not do, so nobody relies on it for more. It is not a sandbox: a recursive delete aimed at a real subdirectory passes untouched, including outside the workspace. It cannot see an expansion — rm -rf "$OUT" is allowed, because guessing at variable values would refuse working commands; your command is caught only because the operand that reaches the delete verb is a literal \ in the text itself. It does not build a blocklist of destructive programs (find -delete, git clean, shred are out of scope). And it fails open on anything it cannot split confidently.

I could not reproduce the deletion itself — no Windows host here — so the evidence is the tokenizer measurement above plus your stderr, not a re-run of the incident. The core fix is still the one your items 1, 2 and 4 describe.

[samvallad33]

Hi ZyptusOn, thanks for posting such a clear log. Since the quoting fix, have you kept approval on never, or moved risky commands back behind a prompt? Running with approval off is exactly when a recursive delete near the drive root should still need a fresh yes, and Vestige, the open source tool I built, enforces that outside the model and keeps a receipt for every command it allowed or stopped. Happy to show you how it would fit your setup. Sam