DeepSeek 在 DSH 中误用 PowerShell $home，导致对用户主目录发起递归删除

[YesSanSan]

事故发生：2026-10-06；补充取证：2026-10-08。本文时间均为北京时间（Asia/Shanghai）。

摘要

在使用 DeepSeek 驱动 DSH 排查第三方插件告警时，agent 为端到端测试准备了一个 fakehome 目录，并生成 PowerShell 命令清理该测试目录。但它使用了 $home 作为普通变量名。

PowerShell 变量名不区分大小写，$home 与内置只读变量 $HOME 指向同一个变量。赋值失败后，脚本继续执行，随后的 Remove-Item $home -Recurse -Force 实际以真实用户主目录为目标。

Windows 事件日志已确认，与该工具调用对应的 PowerShell 进程启动，并持续产生日志至少约 63 秒。用户主目录下存在广泛目录丢失的文件系统残留，DSH 主目录联接消失、主目录分叉及 SSH 配置与密钥丢失也在调查中得到确认。

1. 事故背景与已知环境

事故前，DSH 默认主目录 ~/.dsh 是一个 Windows 目录联接，指向另一块盘上的 DSH 数据目录。事故时运行的 dsh web 没有设置 DSH_HOME，因此仍使用默认主目录路径。

当时正在排查第三方插件 dsh-better-edit@1.0.0 的 snapshot vacuum skipped… 告警。危险操作来自排查过程中 agent 生成的测试清理命令。

已知环境信息如下：

项目	已知情况
操作系统与文件系统	Windows，受影响用户主目录位于 C: NTFS 卷
PowerShell 版本	7.6.6
模型	DeepSeek V4.1 Flash (Command Code API)
事故时 DSH 版本	0.2.1-alpha.1
事故时沙箱与审批	完全权限

2. 直接触发错误的命令

以下是历史危险命令的结构，工作区路径已脱敏。这是事故证据，不应执行。

chcp 65001 > $null
$home = "<workspace>\out\vacuum-repro\fakehome"
Remove-Item $home -Recurse -Force -ErrorAction SilentlyContinue
node "<workspace>\out\vacuum-repro\e2e.mjs" $home 2>&1 | Out-String -Width 200

agent 的意图是给测试指定一个假的 HOME，并清理先前测试产物。实际发生的语义变化是：

1. PowerShell 将 $home 视为内置 $HOME。
2. $HOME 是只读变量，赋值失败，原值仍是用户主目录。
3. 在该命令的错误处理语义下，赋值错误不会自动阻止后面的语句。
4. Remove-Item 读取保留下来的真实 HOME，发起递归强制删除。
5. 删除命令上的 -ErrorAction SilentlyContinue 抑制非终止错误的显示，使权限拒绝或其他删除失败更难从常规输出中察觉。

SilentlyContinue 没有把“赋值失败”变成“赋值成功”；危险点在于赋值失败后仍继续使用旧值执行删除。它也不表示删除一定全部成功：部分对象可能被权限、占用或其他错误阻止，已经完成的删除则不会自动回滚。

原事故记录包含对“只读变量赋值报错后继续执行、变量保持原值”的实测。这一语言行为可以通过纯赋值和输出独立核查，无需进行删除复现：

# 仅观察变量行为，不包含文件操作。
& {
    $ErrorActionPreference = 'Continue'
    "Before: $HOME"
    $home = '__DSH_FAKE_HOME_PROBE__'
    "After: $home"
}

3. 关键时间线

时间	事件	证据与边界
10-05 22:25:47	最后一次有成功远端输出的 SSH 调用	支持当时 SSH 配置与认证链仍可用，私钥存在
10-06 11:03:11.515	危险工具调用写入会话记录	原会话 seq366；后续合成闭合记录复用此时间
10-06 11:03:11.718	对应 PowerShell 进程启动，PID 43136	PowerShellCore/Operational，RecordId 1634201
10-06 11:03:32 起	同实例事件包含完整危险命令	Host / Runspace 身份一致，排除了后续 PID 复用
10-06 11:03–11:05	大量已释放用户目录 MFT 记录的元数据变更时间集中出现	与危险进程活动时间吻合；不是逐文件成功删除日志
10-06 11:04:14.867	最后可见同实例事件	证明进程在此时仍有活动，不能当作真实退出时间
10-06 11:13:15	DSH 在默认路径新建普通空主目录	原联接已消失，主目录出现分叉
10-06 11:13:23	打开原会话时报 ENOENT … session.v4.jsonl.zstd	原会话数据仍位于另一块盘的联接目标中
10-06 11:51:59–11:52:03	合并分叉数据、重建目录联接	合并 7 个文件；原记录确认无会话数据丢失
10-06 12:15:19–12:15:20	最早留存的工具检查结果显示 .ssh 不存在	seq392 是检查调用，seq393 是返回 .ssh False 的结果；这不是用户已知悉 SSH 丢失的时间
10-06 12:15:32–12:15:33	初次排查对异常结果作出误判：仍认为用户主目录完整，将 .ssh 缺失解释为可能原本不存在	seq396；未核对此前 SSH 使用历史
10-08 13:30–13:43	用户发现 .ssh 缺失并开始排查	用户发现时间与历史工具检出时间分开记载
10-08	补充 Windows 事件、MFT 与卷影副本取证	撤回此前“危险命令未执行、零删除”的结论

10-06 的初次排查已经暴露出危险目标及目录缺失，但“工具检出异常”“确认损失”“明确告知用户”没有形成完整闭环。已读取的历史片段中，agent 一度作出用户目录完整的错误判断；后续对用户说明了命令风险，用户手工检查，未发现。

4. 已观察到的影响

4.1 DSH 主目录分叉与会话中断

原 ~/.dsh 联接消失后，运行中的 DSH 仍使用相同的默认路径字符串，并在该位置新建了普通空目录。于是，同一逻辑主目录对应的数据分成两处，打开原会话时发生 ENOENT: no such file or directory, open ...session-a8028f47-99e5-4f37-a2e6-aca1dc32cf7e\session.v4.jsonl.zstd。

后续修复将分叉数据合并回原存储位置，并重建联接。原事故记录确认会话数据未丢失，之后设置了显式 DSH_HOME。

当前 PowerShell 7.6.6 程序集的链接删除分支会删除联接本体，这与“C: 联接消失、另一块盘的目标数据仍在”相容。

4.2 SSH 配置与私钥丢失

Windows 用户主目录的 .ssh 缺失，原有 Host 别名配置不再可用，部分私钥尚未恢复。

4.3 影响超出 .dsh 和 .ssh

取证发现用户主目录下多个旧目录的已释放 MFT 记录，包括 .cargo、.docker、.gradle、.jupyter、.local、.nuget 等。它们的元数据变更时间大量集中在危险进程活动附近。

当前卷与 10-07 卷影副本交叉核对得到 37,989 条已释放候选记录，其中 37,962 条的 $STANDARD_INFORMATION 变更时间落在 10-06 11:00–11:14。另有 25 个已释放目录记录直接引用用户主目录的文件引用，其中 23 个的相关时间落在该窗口。

这些数字是取证候选记录计数，不能写成“该命令删除了 37,962 个文件”。 MFT 元数据时间不等于精确删除时间；记录槽复用、筛选范围和目录重建都会影响统计与解释。完整损失清单尚未确定。

5. 此前的“未执行、零删除”判断不成立

10-06 初步调查曾把会话中断、根层文件仍在、没有预期测试产物等现象解释成“命令没有执行或没有删除文件”。10-08 的补充取证推翻了这些排除理由。

本次进一步核查 10-06 的会话导出发现，seq393 的工具结果已经返回 .ssh False，但紧随其后的 seq396 仍将用户主目录判断为完整，并把 .ssh 缺失解释为可能原本就不存在。该片段的对用户回复提到了危险 $HOME 冲突及继续检查，却没有明确告知 SSH 目录已经丢失。工具检出、agent 对损失的确认和用户知悉是不同事件。

• 会话的合成“结果未知”不是进程已停止的证明。 相关结果带有 ToolOutcomeUnknownError / TOOL_OUTCOME_UNKNOWN。后续源码复核发现，恢复机制复用最后持久事件的时间生成闭合记录，不查询或终止进程。实际 Windows 日志表明对应进程继续活动至少约 63 秒。
• 用户主目录根层文件仍在，不能证明子目录没删。 当前本机 PowerShell 7.6.6 的删除实现先递归子目录，再处理本层普通文件，最后删除目录本体。根层文件保留与部分子目录已删除可以同时发生。
• 当前目录存在，不证明事故前目录保留。 例如当前 .cache 的创建时间是事故后的 11:59:12，不能据其存在排除先前清理。
• 没有后续 Node 测试产物，不能排除前置删除。 删除命令位于 Node 命令之前；删除部分执行后，后续测试仍可能没有启动或没有完成。
• 没有 subprocess 输出文件，不证明未启动。 后续复核的输出收集器只在输出超过阈值时才创建 spill 文件，缺少文件不能作为未执行证据。

6. 当前可以得出的结论与待核查项

已确认： agent 生成了危险命令；对应 PowerShell 进程实际启动并持续活动；用户主目录下存在广泛释放记录；DSH 主目录分叉和 SSH 丢失得到确认；原“零删除”结论已撤回。

高可信原因推断： $home 与 $HOME 冲突，使清理测试目录的操作转向真实用户主目录。该调用与广泛清理残留在时间、范围和现象上高度吻合，是当前首要原因解释。

仍未确认： 每个缺失对象与 PID 的直接对应、精确删除数量、真实退出或取消时间、后续 Node 是否执行。

现存 USN 日志及可用卷影副本中的 USN 已滚动覆盖事故窗口，现有审计材料也没有提供逐文件到 PID 的映射。

7. 希望讨论的 DSH 防护改进

7.1 为测试提供任务专属临时目录

涉及 fake HOME 的端到端测试可以由 harness 提供专属目录及受限清理能力，目录位置、归属和可删除范围由 harness 管理，减少模型手写任意路径递归清理的机会。

7.2 区分会话中断、结果未知与进程终止

建议在执行记录中分别保留进程启动时间、PID 与实例身份、取消请求时间、终止是否成功及实际退出状态。

会话恢复生成的历史闭合事件应明确标注为合成事件，避免复用时间戳在 UI 或后续调查中被误读为真实执行时长。取消或中断也应明确表达为停止后续执行的动作，不能暗示已完成的文件删除被回滚。

7.3 保留可用于事故核查的执行审计

每次工具调用至少应能关联：命令、工作目录、有效权限与沙箱档位、审批决定、进程实例、退出或终止结果。记录需要在会话未正常收尾时仍可查询，并避免泄露凭据。

同时，DSH 主目录联接意外消失时，建议提供明确诊断，避免在原路径悄然初始化第二份主目录，使数据分叉进一步影响排查和恢复。

[argszero]

Thanks for writing this up the way you did — separating "MFT candidate records" from "files deleted", and withdrawing the earlier zero-deletion conclusion instead of defending it, is what makes the report usable. Two things I can add from the source side: what has to be true for that command to do this, and where a check can sit before the body runs.

The trigger is a name collision, and the danger is invisible in the text

I could not reproduce it here — this host is macOS with no PowerShell installed, so everything below is read out of the repository plus the language's documented semantics, not from a local run of your probe.

$HOME is a read-only automatic variable in PowerShell and variable names are case-insensitive, so $home is $HOME. The assignment fails as a non-terminating error; $ErrorActionPreference defaults to Continue, so the next statement runs anyway and Remove-Item receives the real profile path. So the command needs all three of: a name that collides case-insensitively with an automatic/reserved variable, error semantics that let the statement after the failed assignment proceed, and a destructive verb whose target is a variable rather than a literal.

That distinguishes the amplifiers from the cause. -ErrorAction SilentlyContinue did not cause this — it only made the individual removal failures quiet in the transcript; deleting it would not have prevented the deletion. And the literal command text contains no dangerous path at all: a gate that looks for C:\Users\…, $env:USERPROFILE or ~ never fires here. What identifies the call is knowing PowerShell's automatic-variable set, not extracting a path from the string. That is also why "the model should have noticed" is not a satisfying answer — the offending argument, read as text, looks like cleaning up a variable the script just defined.

Why the layers that do exist didn't catch it

Confinement would have. The profile directory is outside any workspace, so read-only or workspace-write cannot reach it; the report's "full permissions" is precisely the mode in which the target stops being protected. The gap is therefore an argument-level check in full-permission mode, not a sandbox hole.

The intended seam already exists in the tree

tools/pre-execute is declared as "allow, deny, cancel, or ask before dispatch", and a deny short-circuits the pipeline — the tool body never runs (pinned by packages/core/tools/tests/tools.spec.ts, "a pre-execute deny short-circuits before tools/execute"). The header of packages/shell/tool-bash/src/index.ts carries the matching TODO: deployment policy belongs in tools/pre-execute and in sandboxing executors. Both shell tools (bash, and pwsh in Windows compositions, whose parameter surface deliberately mirrors it) expose their command as the command argument of a ToolExecution, alongside the calling agent — enough to decide before execution. Today the only risk-oriented listener there is experimental/auto-review, which is model-based and only active on the auto preset, so a deterministic check is unclaimed ground.

We are building that as a plugin: it denies when a reserved automatic-variable name is assigned in the same command as a recursive-and-force delete (Remove-Item … -Recurse -Force, rm -rf, rd /s /q, del /f /s /q) whose target is a variable, ~, or a filesystem root, and it denies rather than asks in that case because the assignment has already failed. It mounts as a normal DSH plugin, so no core change is involved; I will post the package here when it lands. If you think the automatic-variable list should cover more than HOME / PSHOME / PROFILE / PWD and friends, say so — I would rather cover the set than the one example.

Two mitigations that generalise, usable today

• $ErrorActionPreference = 'Stop' (or -ErrorAction Stop on the assignment) makes the failed assignment terminating, and the delete never runs. That is a fix for the whole class, not just for $home.
• On anything destructive, avoid -ErrorAction SilentlyContinue; it is what kept the partial failures out of the visible transcript.

One confirmation of your §5

Your point that the synthetic "outcome unknown" is not evidence the process stopped checks out in the source: packages/core/session/src/repair.ts synthesizes the closing tool/result from this.last.time — the last persisted event's time — and never queries or terminates the process. The ToolOutcomeUnknownError / TOOL_OUTCOME_UNKNOWN code path is a log repair, and the only reliable question about "did it keep running" is the OS-side record, which is what you went and read.

[argszero]

An installable guard for this, if the harness wants one

The analysis in the reply above stands on its own. But the gap it describes has a shape a plugin can close today, so I published one:

• npm: @argszero/dsh-destructive-command-guard@0.1.0 — https://www.npmjs.com/package/@argszero/dsh-destructive-command-guard
• source: https://github.com/argszero/dsh-destructive-command-guard

npm install @argszero/dsh-destructive-command-guard@0.1.0

- insert:
    - id: destructive-command-guard
      name: '@argszero/dsh-destructive-command-guard'

It listens on tools/pre-execute and returns deny for the two facts that are certain from the text alone: an automatic-variable name assigned with PowerShell's spelling ($home = …) and then used as the operand of a deletion, and a recursive or forced deletion whose operand is a home reference ($HOME, $home, ~, $env:USERPROFILE, %USERPROFILE%) or a filesystem root. A deny at that seam short-circuits before the dispatch stage, so the tool body never runs — and, unlike ctx.tools.guard, before any approval prompt is put to the operator (packages/core/tools/src/index.ts:1505-1508 versus :1519).

The reason it returns is written to be acted on, because a refusal the model cannot act on costs a turn:

Error: destructive-command-guard refused this command before it ran.

Command read as:
$home = "C:\work\out\vacuum-repro\fakehome"
Remove-Item $home -Recurse -Force -ErrorAction SilentlyContinue

• automatic-variable collision (`home`)
`$home = …` does not create a variable. In PowerShell variable names are
case-insensitive, so `$home` is the automatic variable `$HOME`, which is
read-only: the assignment fails as a non-terminating error, and with
`$ErrorActionPreference` at its default `Continue` the statement after it runs
anyway — so `remove-item -Recurse -Force $home` deletes the value the runtime
gave that name, not the one this line appears to name.
Rename the variable (any name that is not a PowerShell automatic variable) and retry.

Nothing was executed.

What it deliberately does not refuse: a recursive forced deletion of an ordinary variable (rm -rf "$BUILD_DIR"), a subdirectory of the home directory (rm -rf ~/scratch), or a path that merely looks sensitive. A guard that refuses ordinary work is a guard that gets unmounted, and an unmounted guard protects nothing. mode: 'report' logs what it would refuse without refusing it, so it can be measured before it is trusted; exempt and protectedPaths are the escape hatches; and the scan fails open — an error in the plugin's own reading is logged and the call proceeds, because a plugin bug that refuses every tool call is a worse failure than the one it prevents.

Honest boundaries, since they decide whether this substitutes for a core fix:

• it is a lexical scan, not a parser — a command built at run time, or a name reached through a wrapper script, is a miss rather than a false accusation;
• it is not a sandbox: it refuses a shape, it does not confine a process;
• I could not reproduce the incident locally. There is no PowerShell on the machine this was built on, so the rules were verified against the reported command text and the PowerShell language rules, not by watching $home delete a profile.

Evidence, because a guard is worth exactly what it refuses: 50 tests, in which the incident is refused end to end through the real ToolRuntime and every refusal is paired with a control arm that runs the same command with the plugin absent (so "the result was an error" becomes "the plugin caused the error"); 35 defect-injection arms, all caught, none leaving the suite green; and both peer lines the package claims (0.1.7-rc.2, 0.2.0-rc.2) probed with every harness package pinned to that line and the pins read back before the suite runs.

Whether the harness wants a deterministic guard at this seam is the maintainers' call — experimental/auto-review is the only thing sitting there today, and it is model-based. The plugin does not depend on that decision: it mounts, it refuses, and unmounting it changes nothing else.