【BUG】数据事故报告：跨 wsl.exe 传参时变量被二次展开，rsync --delete 目标退化为 /，本地 D 盘被删除 1.8 万个文件

[Dada727]

摘要

一条意图完全正常的"把项目目录同步进 WSL 构建目录"的命令：

wsl.exe -d Ubuntu-22.04 -- bash -lc 'cd /tmp/work && for d in src include tests; do rsync -a --delete /mnt/d/<项目目录>/$d/ $d/; done; echo SYNCED'

在 wsl.exe 边界丢掉了引号保护，循环变量 $d 被展开为空，$d/ 退化为 /，实际执行变成：

rsync -a --delete /mnt/d/<项目目录>// /

即以 / 为删除目标（/mnt/d 就是 Windows 的 D 盘）。命令跑满 120 秒超时才被强杀，期间删掉 18,419 个文件/目录，涉及 4 个顶层目录（编辑器安装目录、源码目录、Python 实验目录、一个会议软件安装目录）、2 个临时目录和游戏数据的一部分。删除为 unlink，不进回收站；D 盘无卷影副本，最终只靠编辑器本地历史救回 184 个源码文件。

本文是用户复盘，不是团队结论。

环境

项	值
系统	Windows 11（本地 MSYS Bash 执行环境）
DSH	桌面版 44.7.0，nightly 通道
dsh-ops	0.3.0（profiles/desktop/node_modules/dsh-ops）
会话权限	文件沙箱 danger-full-access，审批策略 never
WSL	Ubuntu-22.04，项目位于 /mnt/d/...

时间线

时间	事件
15:08:04	模型发出上述 run_code → ops_bash 调用（timeoutMs: 120000）
15:08:05	子进程启动，stderr 日志创建（最终 53.7 MB / 315,759 行）
15:08:24	第一条删除记录（NTFS USN，精确到秒）
15:08:24–15:09:26	删除爆发，峰值约 200 条/秒，共 18,419 条
15:10:04	触发 120 秒超时，返回 AbortError，rsync 被强杀
15:10:08	下一条命令 cd /tmp/work 报 No such file or directory（WSL 侧已被清空）

根因

1. 命令层面：跨 shell 边界丢引号

• Windows 侧 shell 收到的是 wsl.exe ... -- bash -lc '<带单引号的整段脚本>'。
• 单引号是给 Windows 侧 bash 的；引号被消费后，传给 wsl.exe 的 argv 里已没有任何引号。
• wsl.exe 不保留 argv 边界：-- 之后的参数被重新拼成一行命令行文本交给 Linux 侧再解释一次。这一层 $d 失去保护，而该层没有变量 d，于是展开为空。

需要强调：这是"正常写法 + 平台参数边界"的结果，模型写对了单引号。

2. 平台层面：四个该拦没拦

1. ops_bash 对跨 shell 传参零感知：命令里出现 wsl.exe ... bash -lc '<...>' 这种把脚本塞进另一个 shell 的结构时，没有任何引号/变量边界提示。
2. 高危模式零拦截：rsync --delete 目标为 /、rm -rf /、find / -delete 这类模式没有闸门，也没有 --dry-run 或"目标必须是绝对路径且长度大于 N"的校验。
3. 最宽松权限组合无二次确认：danger-full-access + approval=never 下命令直接执行；唯一兜底是 120 秒超时，而它只限制时长，删除按目录顺序推进，反而变成"删一部分就停"的随机伤害。
4. 沙箱对 /mnt/d 无效：Windows 沙箱策略管不到 WSL 内部路径，/mnt/d 实际就是宿主机 D 盘，但工具侧看不到这层映射。

证据

证据	说明
子进程 stderr（53.7 MB / 315,759 行）	首行 rsync: [generator] chgrp "/." failed: Operation not permitted (1) 证明目标根是 /；Read-only file system 207,417 次、Permission denied 103,294 次；全日志只有一次 rsync 运行，SYNCED 出现 0 次，说明第一轮迭代就跑向 /
会话 journal（session.v4.jsonl.zstd）	15:08:04.792 记录该命令原文与 timeoutMs；15:10:04.861 返回超时
NTFS USN 日志（412,741 条，覆盖 4 天）	删除对象与时间精确到秒，与时间线吻合；D 盘根目录 LastWriteTime 与最后一条删除记录同为 15:09:26
代码核对	dsh-ops@0.3.0：lib/shells.js:1070 以 [file, '-c', command] 传递，lib/session-shells.js:42 与 44-54 在 danger-full-access 下 prepareArgv 直接返回原 argv，不做改写。说明 DSH 自身没有篡改命令，问题在跨 wsl.exe 的解释层

建议（按优先级）

1. 高危命令闸门：对 rsync（任何 --delete）、rm -rf、find -delete、shutil.rmtree 等，在被删目标解析为 /、~、$HOME、单层目录或与工作区无关的绝对路径时硬拦截并要求确认。
2. 跨 shell 提示：检测到 wsl(1).exe ... -- <shell> -l?c '<脚本>' 或嵌套 bash -c 时，提示"引号只在本层有效，变量可能在下层被二次展开"，建议改为写入临时脚本文件再执行。
3. 记录最终命令行：把 wsl.exe 等外部边界实际收到的命令行文本写进审计日志，否则事故后无法还原最终执行形态（本次只能靠 stderr 反推）。
4. 权限组合护栏：danger-full-access + approval=never 时，对含删除语义的命令强制一次确认，或默认加 --dry-run。
5. 路径映射感知：把 /mnt/<drive> 与宿主盘符关联起来，让沙箱/审计知道 WSL 内路径落在哪个卷。

待验证的最小实验

WSL 在这台机器上已被同一次误删波及（D:\WindowsApps 被清空，wsl.exe -l -v 现返回 Wsl/E_ACCESSDENIED），暂时无法复现。WSL 恢复后可用无副作用命令确认边界：

wsl.exe -d Ubuntu-22.04 -- bash -lc 'cd /tmp && for d in a b; do echo "DEST=[$d/]"; done'

若输出为 DEST=[//]、DEST=[//]（而不是 DEST=[a/]、DEST=[b/]），即确认二次展开发生在 wsl.exe 边界。

同类已知问题：microsoft/WSL#3284、microsoft/WSL#11635。

---

以上为完整事故记录（含时间戳与证据链），需要更细的字段级细节或原始命令/日志片段我可以补充。

[Big-Dao]

根据我这两年Coding Agent编程的切身体感，LLM无论是在powershell上还是CMD的表现要远远差过linux下posix shell工具链，而且有些错误相当低级，用起来百感交集。毕竟，用来训练LLM的开源代码库使用posix shell工具链的数量不知道要比powershell/CMD高出几个数量级，LLM在斜杠、反斜杠......各类差异上颇费心智。

微软在纳德拉接手后没多久，就拥抱Linux，推出了WSL，开发体验相当良好，这些年来，我都是优先在WSL下干活。

在deepseek harness for windows发布后，dsh拥有了windows原生应用的流畅和便利，但是官方没找到类似VS Code的Remote-WSL扩展的WSL插件，如果想用posix shell工具链，就只能在web ui下用，但是浏览器中的web app受到的限制太多了。于是搓了插件，为了安全，还特意支持了沙箱，以尽量避免倾巢之祸。

朋友们可以试用一下。插件初启，还有非常多问题，欢迎任意意见和建议。

#11251
https://github.com/Big-Dao/dsh-plugin-wsl-env

[aturzone]

I triaged this against dsh-ops 0.3.0 and DSH master fcc0ad4621. The data-loss chain is credible, but the WSL layer needs a correction: -- is not an argv boundary and does not itself requote anything. The fix is -e/--exec or a script executed inside WSL.

Confirmed

dsh-ops 0.3.0 passes the command unchanged: lib/shells.js:1070 builds [file, '-c', command]; lib/session-shells.js:42-54 under danger-full-access returns the original argv after prepareWorkspace and a policy recheck. There is no rsync --delete/rm -rf gate in 0.3.0.

DSH core has no built-in dangerous-command gate either. packages/shell/tool-bash/src/index.ts:9-10 leaves policy to tools/pre-execute/sandboxing executors, and packages/shell/bash-sandbox/src/index.ts:92-96 skips confinement for danger-full-access. never is not a fallback confirmation: packages/interaction/user-approval/src/index.ts:296-301 resolves every ask to rejected. I could not verify the deletion counts or the USN/stderr files; the reported chgrp "/." and zero SYNCED fit a / destination.

WSL semantics

wsl --help says -e, --exec runs "without using the default Linux shell", while -- means "Pass the remaining command line as-is." As-is is a command-line string, not argv. In current WslClient.cpp on microsoft/WSL master, -- only breaks option parsing and leaves shell mode; shell mode passes the remaining text to $SHELL -c (around lines 1822-1853). -e sets UseShell=false, parses with CommandLineToArgvW, and execs directly (lines 1658-1662, 1836-1844). Windows passes wsl.exe a command-line string, not argv: the Windows-side bash consumed the single quotes and serialized the script into a Windows command line. The encoding most consistent with your stderr is a double-quoted argument, so the WSL shell expands $d empty inside those quotes before bash -lc sees the script. The observed result is real, but it is not wsl.exe re-joining argv after --; -- does not disable the extra shell. microsoft/WSL#3284 and #11635 show the same extra shell/quoting behavior; #11635 was closed stale, not fixed. The installed WSL build is not stated; the A/B test settles the local behavior.

A Windows-side .sh run through ops_bash script_path does not automatically fix this: it can still call wsl.exe ... -- bash -lc '...'. Execute the script inside WSL, or use -e.

A/B test (zero side effects)

Once WSL is restored, run both from the same MSYS bash ops_bash uses, not PowerShell:

wsl.exe -d Ubuntu-22.04 -- bash -lc 'for d in a b; do printf "DEST=[%s/]\n" "$d"; done'
wsl.exe -d Ubuntu-22.04 -e bash -lc 'for d in a b; do printf "DEST=[%s/]\n" "$d"; done'

A should print DEST=[/] twice; B should print DEST=[a/] and DEST=[b/]. If A is correct, the Windows-side serialization protected $ on that machine and another cause is in play; report it.

Safe form

wsl.exe -d Ubuntu-22.04 -e bash -lc '
set -euo pipefail
cd /tmp/work
for d in src include tests; do
  src="/mnt/d/<project>/${d:?}/"
  dest="/tmp/work/${d:?}/"
  rsync -a --delete --dry-run "$src" "$dest"
done
'

${d:?} aborts if any layer expands d empty; -e removes the extra shell. Drop --dry-run only after the listing is correct. For the actual sync, put the script on a healthy volume and run wsl.exe -d Ubuntu-22.04 -e bash /mnt/c/Users/<you>/sync.sh.

The four guards

Report gap	Seam at fcc0ad4	Plugin today?
Cross-shell awareness	tools/pre-execute / ctx.tools.guard() (packages/core/tools/src/pipeline.ts:199-213, packages/core/tools/src/index.ts:384-405)	Yes. dsh-ops already registers both for host-shell denial (lib/index.js:60-62); the same hook can inspect exec.name === 'ops_bash' and exec.arguments.command.
High-risk gate	same; PreToolDecision supports deny/ask (packages/core/tools/src/contracts.ts:357-364)	Yes for deny/ask. Detection is heuristic: the / here came from expansion, so a literal-/ regex would miss it. Input rewriting is excluded, so --dry-run injection belongs in the ops_bash body (lib/shells.js), not the generic hook; do not make it silent.
danger-full-access + never confirmation	ask routes to approval (packages/core/tools/src/pipeline.ts:203-205,436-469)	A plugin can ask, but never auto-rejects: that is a hard denial, not a prompt. A real prompt requires approval ask; changing never is core.
/mnt/d sandbox visibility	ctx.sandbox/ctx.sandboxPolicy; Windows ACL	No. danger-full-access disables confinement, and packages/sandbox has no /mnt/<drive> to volume mapping. Needs core/provider work.

DSH logs the model's command, but not the command line MSYS bash builds for wsl.exe; a plugin can log its own argv; capturing the actual Windows boundary needs a wrapper or OS-level tracing, which is a core change.

Recovery

rsync unlinks, so the Recycle Bin is not a recovery path. Stop writes to D: (indexers, game clients, installs, downloads) and do not install recovery tools on it. Image the volume before repairs if possible; then check vssadmin list shadows /for=D:, File History/backups, editor local history, and $UsnJrnl for names/timestamps (not contents). Run winfr or another tool from a different drive, output to a different drive; avoid chkdsk /f/defrag before imaging.

I reproduced the two-layer expansion locally with bash, but not the deletion or the Windows serialization; the source and current WSL master behavior above are what I verified.