【悲】被glm的3亿token清洗的干净C盘

写这个话题希望各位佬友在抢鸡蛋的时候注意一下鸡蛋的新鲜程度^-^

以及如果可以 有条件的话 让这些低智商模型运行在虚拟机或者沙盒里面吧。。。

我玩ai玩了快一年了 终究还是掉坑了

各位老友一定要注意一下了 目前我的损失就只有claude+codex的部分聊天记录和未完成的项目（已及时传github）

背景

在 keep-enter 项目里让 ZCode 写了一个 ke 脚本（在 Ubuntu 的 screen 会话里自动确认 Claude Code 审批对话框的小工具）。脚本经过评审修复后，那个会话（sess_a7da40b6）跑一条“冒烟测试”命令来验证功能。命令的本意是完全安全的：把 HOME 重定向到临时沙盒 /tmp/ke-smoke，在沙盒里测试，全程不碰真实主目录。

今天 07:42:25 — 事故命令启动

命令开头：cd keep-enter && export HOME=/tmp/ke-smoke && rm -rf "$HOME" && mkdir -p "$HOME" && ... && sleep 60 & SPID=$! ; ...

致命缺陷在这里：& 的优先级高于 &&，所以 & 前面的整段链——包括 export HOME=/tmp/ke-smoke——被整体丢进了后台子进程执行。前台 shell 的 HOME 从头到尾都是真实主目录 /c/Users/Administrator。于是前台继续执行时：

• 往 $HOME/.ke/ 写了 pid 文件和 2MB 测试日志 → 写进了你的真实主目录；


• bash ke on mytask 用真实 HOME 启动；


• 最后的清理步骤 rm -rf "$HOME" → 实际执行了 rm.exe -rf /c/Users/Administrator。

07:42+ — 火绒拦截

火绒 log.db 里恢复出了原始记录：文件防护 v6 引擎的 “touch startup” 规则看到 rm.exe 的命令行目标覆盖整个用户目录（内含受保护的“启动目录”），判定高风险，直接对进程本身阻止/终止（PID 33364）——是主动拦截，不是等它删到 Startup 文件夹才反应。日志中针对本次事故的拦截记录只有这一条。rm 在被终止前的短短窗口里删掉了一批小体量配置文件，Startup、AppData 主体、桌面文档等全部保住。

07:42–08:15 — 损失定格，部分自动重建

• 运行中的软件各自重建了自己的目录：Codex 08:22 重建 .codex，ZCode 框架重建了 .zcode/cli；


• 出事会话自己又工作了片刻（ke/README 最后修改于 08:14），随后它的本地执行日志（cli/exec/sess_a7da40b6/）也在删除中丢失——所以那条命令的结尾部分本地已无法复原，我是靠云端会话历史 + 火绒存档的完整命令行把根因拼出来的；

更多经过请看： 【悲报】电脑文件被清空【爱来自zcode的友善清理】 - 搞七捻三 - LINUX DO