Agent 清个临时目录，顺连接点删光活文件：我钉的三道闸
大家好，我是珂抖屁。
公开讨论里反复出现同一类事故：人让 coding agent「清一下临时目录 / 拆掉不用的 worktree」，Agent 回一句接近「弄坏了一些东西」——盘上已经少了成千上万个还在用的文件。
刀口不在「模型会不会撒谎」，在 Windows 上的 junction（连接点）+ 递归删除。pnpm / npm workspaces 常在 node_modules 里造 NTFS 连接点；Git Bash 的 rm -rf、PowerShell 的 Remove-Item -Recurse -Force、乃至某些 harness 自带的 worktree 清理，会顺着连接点走进真实目标目录，把仓库源码、用户目录、甚至整份资料树删掉。回收站不一定拦得住。
时间线上也有人把这类帖推到热议（公开锚之一：x.com/i/trending/2101717157436604565）。我这篇不追热闹数字，只钉一人公司能立刻装上的闸：权限边界、备份、followlinks 实操。
现场长什么样
公开 issue 里，模式高度相似，我压缩成四句：
1.任务本身很「合理」：删失败的克隆、清 stale worktree、卸一个变体目录。
2.目录里有 NTFS junction——指向主仓、共享 node_modules、甚至用户配置树。
3.Agent 或 harness 家政跑了递归删除；工具把连接点当普通目录往下走。
4.删完才发现：目标外的活文件没了；有的会话记录里甚至看不到对应删除命令——清理发生在后台 housekeeping。
公开 issue 里三类翻车都见过：跟 pnpm 连接点走出项目树、跟 workspace junction 掏空主仓源码、harness 后台清 worktree 时无提示删掉连接点背后的数据。受害量级以当事人与仓库记录为准，我不当段子复读。
结构结论就一句：在 Windows + 包管理器连接点 + 递归删除 这条组合上，「清临时」可以等于「清生产」。
为什么「权限点过了」仍不够
一人公司常见两种假安全感：
•我开了确认：确认的是「删这个路径」，不是「这个路径里每个 reparse point 指向哪里」。
•我没用 --dangerously-skip-permissions：有些清理根本不走你眼前那条工具调用——重启、合盖后唤醒、stale worktree 回收，可能直接家政删除，会话 transcript 里查无此令。
所以闸不能只做在「模型乖不乖」上，要做在删除语义和文件系统事实上。
三道闸：权限边界、备份、followlinks
三道闸：权限边界 / 备份 / followlinks
闸一：权限边界——递归删默认高危
我给 Agent 的删除纪律，写成可贴在 CLAUDE.md / AGENTS.md 一类入口的短句：
•Windows 上禁止对含 node_modules、worktree、用户主目录的路径直接 rm -rf / Remove-Item -Recurse -Force。
•先列 reparse point：dir /AL、fsutil reparsepoint query，或任何你熟的「只列连接点」脚本。看见指向仓库外、用户目录、数据盘的连接点——先拆连接点，再谈删目录。
•需要删目录时，优先走「只摘链接、不追随目标」的路径；具体命令以本机实测为准，别背网上口诀替行为担保。
•用户主目录、盘符根、含 junction 的 worktree，默认拒绝自动递归删；要删必须二次确认，并写清「将追随哪些连接点」。
权限模型的目标不是「Agent 不能干活」，是让「清临时」跨不出临时。
闸二：备份——删之前要有可回滚面
Agent 现场最贵的不是 token，是不可回滚的删除。
我的最低备份条：
•源码：进 git，且 push 过；裸工作区被掏空还能 git restore / 再 clone。
•不进 git 的数据（日志、采集、本地密钥旁路文件）：删前快照或至少拷到 Agent 写不到的盘。
•高危清理任务：先在无真实 junction 的沙箱副本演练一遍删除命令，再碰真树。
公开案例里，有人靠 git index 救回源码，也有人业务数据上游只留几天——能进版本库的进版本库，不能进的别让 Agent 当临时目录清。
闸三：followlinks——把「跟不跟链接」写成显式开关
POSIX 里人们习惯讨论 symlink follow；Windows 上同等要命的是 junction。我要的实操不是论文，是检查清单：
1.任务拆开：「删 worktree 元数据」和「卸 node_modules」分开下；禁止一条「把这个文件夹清干净」包打天下。
2.先图后刀：让 Agent 先输出「将删除的路径树 + 识别到的连接点及目标」，人眼扫一眼再授权执行。
3.工具选择：能调用 junction-aware 删除就调用；不确定就人工用资源管理器 / 已知安全的卸链接步骤处理连接点，再让 Agent 删空壳。
4.事后核对：删完立刻 git status、抽查关键数据目录体积与抽样文件；Agent 说「弄坏了一些东西」时，默认按事故升级，不按俏皮话忽略。
followlinks 闸的本质是：递归删除的默认假设改成「连接点可能指向活数据」。
边界：这不是「别用 Claude」
公开问题多落在 Claude Code + Windows + pnpm/worktree，不代表别的 harness 免疫——凡代你递归删除的 Agent，都可能踩连接点语义。这波热议主战场在 NTFS junction。
我不主张关掉 Agent 文件工具。要收的是高危删除的默认策略，不是生产力本身。
今晚就能做的最小动作
若你此刻就在 Windows 上跑 Agent，不必等完美策略：
1.对常用仓库跑一次连接点清单，把结果存进笔记，不当一次性好奇。
2.把「递归删除」从默认允许里拿掉，改成需你粘贴确认词才执行。
3.确认源码已 push；不进 git 的数据目录，写进 Agent 的禁删名单。
三步做完，你对「清临时」的恐惧会从情绪变成清单。清单比情绪便宜。
也提醒一句：把闸写进入口文件之后，还要抽查 Agent 是否真的服从——公开事故里不乏「纪律写了、临时任务一急又直接 rm」的情况。闸是给双方看的：你和模型。
我自己的判断
Agent 可以帮你干活，但不能替你理解 NTFS。
「清临时目录」在连接点世界里，可能是清你的活资产。权限点过了不够，备份没有不够，删除命令不声明 follow 语义不够。三道闸里，我最看重的是第二道——没有可回滚面，前两道全是表演。
若你本机也是 Windows + pnpm / 多 worktree，与其等下一次「弄坏了一些东西」，不如今晚先跑一遍连接点清单。清单是空的，你才配说「临时目录可以自动清」。