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

作者：#Nyuaaa 板块：#搞七捻三 写这个话题希望各位佬友在抢鸡蛋的时候注意一下鸡蛋的新鲜程度 以及如果可以 有条件的话 让这些低智商模型运行在虚拟机或者沙盒里面吧。。。 我玩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 的命令行目标覆盖整个用户目录（内含受保护的“启动目录”），判定高风险，直接对进程本身阻止/终