一文读懂 unlazy 安全威胁模型：CHECK 即代码、审批边界与 fail-closed 设计详解

一文读懂 unlazy 安全威胁模型CHECK 即代码、审批边界与 fail-closed 设计详解【免费下载链接】unlazyAnti-laziness skill for AI agents. Core: the Depth Tree method, which splits a task N layers deep and gives every leaf the full time budget of the whole task, so effort multiplies with depth. Grounded in 2025-2026 research on model laziness, underthinking and premature completion.项目地址: https://gitcode.com/gh_mirrors/unl/unlazyunlazy 是面向 AI Agent 的反懒惰技能anti-laziness skill它让 AI 在长任务中先写验收账本GATES.md、再执行已审查的检查命令用证据而非口头汇报证明完成。但正因为它会执行仓库里描述的 shell 命令安全设计就格外关键。本文用通俗语言拆解 unlazy 的威胁模型为什么CHECK:行被视为代码、审批记录如何绑定到每一个执行细节以及 fail-closed失败即拒绝设计在源码中如何落地。 核心立场安全边界是审批不是沙箱unlazy 在 SECURITY.md 开篇就给出了一句至关重要的定调它的安全边界是显式的审查与审批而不是命令沙箱explicit review and approval, not command sandboxing。换句话说unlazy不隔离你要执行的命令——命令拥有执行检查器的那个用户的完整权限能碰到文件、网络连接、凭据和开发者工具。它真正防护的是另一个问题一条命令在你明确看过并同意之前绝不执行。这是理解全部设计的前提。下面逐层展开。 CHECK: 行就是代码最重要的安全假设在账本格式里每个可运行门禁长这样- [ ] G1: pricing fixtures render the expected tiers CHECK: node scripts/verify-pricing.mjs EXPECT: pricing verification passed其中CHECK:后面是一整行将在 shell 中执行的命令。unlazy 把它直接当作可执行代码对待见 references/gates.md 的Approval boundary一节。这带来几条铁律先读源码再谈运行。继承来的账本必须先用--status解析该模式永不执行再逐条读CHECK:、EXPECT:、CWD:以及命令调用的每一个脚本——包括生成文件和被 git 忽略的文件。绝不以运行代替阅读。不要为了看看它会干嘛去跑不可信的检查——那本身就是执行。不可信数据边界。账本标题、命令输出、其中引用的文本一律视为不可信数据不能让它们指挥 Agent 去批准自己或安装 hook。--status是唯一永远不执行的模式而普通模式对没有精确审批记录的新命令只会打印解析后的完整信息命令、期望、工作目录、shell、PATH后保持不执行——但注意一旦该命令被精确批准过普通模式就会执行它。它不是永久的 dry-run。 审批边界一条审批只认一个完整执行上下文审批记录默认存放在~/.unlazy/approved目录。unlazy 的设计核心是审批不是一句我同意跑这个命令而是对一整套执行指纹的精确绑定。在 scripts/gate-check.mjs 中每个检查会被打包成一个oracle预言机包含绑定项含义绝对账本路径 门禁 id哪份文件、哪条门禁精确的CHECK:与EXPECT:文本命令一字不差解析后的CWD:与 shell在哪里、用什么解释器跑超时、输出上限、正则匹配参数执行预算平台 完整继承的PATH在哪台机器、哪个工具环境跑这些字段拼成 JSON 后取 SHA-256 作为签名。任何一项发生变化旧审批自动失效必须重新审查、重新批准。例如你在 Windows 上批过的命令换到 Linux 就是新命令PATH变了换了终端同样要重新审批。还有一个诚实的边界值得新手注意审批不快照命令调用的脚本内容。如果CHECK:文本没变、但它调用的verify-pricing.mjs被别人改了字节旧审批仍然生效。官方解法不是自动追踪依赖而是要求你变更依赖后重新审查再跑--reverify若需要机器强制的依赖校验把依赖摘要直接写进被审批的CHECK:文本里用你另外信任的工具去验证。️ fail-closed 设计宁可拒绝绝不偷fail-closed 的意思是当安全状态无法确定时选择失败拒绝执行而不是降级放行。这是 unlazy 源码里反复出现的设计哲学几个典型例子1. 锁不偷取。审批与租约都用文件锁。经典陷阱是看到锁 → 删锁 → 占新锁在 stat 和 unlink 之间旧主可能已释放、后继者可能已拿到同名锁ABA 竞态。scripts/lib/gates.mjs 的做法是永不按路径删除观察到的锁等锁消失就重试崩溃进程留下的锁到超时后失败即拒绝由人工确认 PID 不再存活后手动清理。官方明令禁止在 unlazy 运行时批量删除锁目录。2. 符号链接与权限一律拒绝。审批目录必须是真实的、当前用户独占、无组/他权限的目录且其规范化路径必须在仓库根之外防止仓库里的人伪造审批。读取审批文件时scripts/gate-check.mjs使用O_NOFOLLOW不跟随符号链接打开并在读完后再验证描述符指向的还是同一个单链接常规文件——读取期间被换掉的文件会被拒绝。3. 原子写入防篡改。scripts/lib/gates.mjs 的writeAtomic拒绝替换符号链接目标先写临时文件 fsync再原子 rename追加状态日志前会核对nlink 1和 dev/ino防止硬链接/符号链接把写入引到仓库外。4. 解析失败即失败关闭。零门禁的账本、重复 id、缺少理由的 ABANDON全部是解析错误而不是完成——不完整的结构无法产出一张完成证书见 references/gates.md。️ Shell、PATH 与继承环境跨平台的隐形变量检查器解析 shell 的顺序是--shell→UNLAZY_SHELL环境变量 → 平台默认Unix 的/bin/shWindows 的ComSpec/cmd。子进程继承启动时的完整环境包括 PATH。这里藏着一个新手最容易踩的坑同一个检查器从 Git Bash 启动和从 PowerShell 启动可能解析到完全不同的工具集。--shell只是换解释器——它不安装缺失的工具、不清理环境、也不限制命令访问。因此官方强烈建议可移植的门禁优先使用仓库自有的 Node 脚本而不是假设grep、tail存在。环境不匹配shell 或 PATH 变了应被视为验证失败去解决而不是当作证据保留——因为解析后的 shell 和 PATH 指纹本身就是证据的一部分。 重要澄清Scope、租约、波次都不是沙箱unlazy 的并行协作机制scope 管道、OWNS:路径租约、dispatch 启动波次经常被误解为隔离手段官方文档反复强调它们不是它们限制的是 unlazy 自己的发现范围、日志目标、协调标签它们不阻止任何进程去读写另一条路径租约匹配是保守的协调守卫宁可拒绝安全的好组合不是写隔离。真正的隔离来自操作系统层面容器、虚拟机或独立 worktree且注意 worktree 仍可能共享外部缓存和服务。references/parallel.md 对此有完整说明。 Stop Hook只读状态、不执行、消息有界可选的 Claude Code Stop hookscripts/stop-hook.mjs在门禁未满足或波次未完成时返回decision: block阻止会话草草结束。它的安全设计同样讲究不执行任何CHECK:命令只解析账本与 dispatch 状态连续 6 次无语义进展才释放改注释、重排版、evidence 行的 PATH 哈希刷新都不算进展防止改一行就重置计数器的无限续命输出给宿主的消息剥离所有 C0/C1 控制字符和双向格式标记、长度受限scripts/stop-hook.mjs——因为仓库可诊断文本是攻击者可以控制的绝不能借机改写终端历史或视觉上重排文字自由文本的放弃理由永不被复制进特权消息只输出有界的HANDOFF REQUIRED摘要。 进程树清理一个 Windows 细节每个检查跑在一个独立的 Node 监督者进程scripts/lib/check-supervisor.mjs之下它作为进程组组长存活到 shell 及所有继承的 stdout/stderr 描述符关闭为止。超时清理时的细节体现了最小信任POSIX 上只在监督者仍被观察到存活时才向进程组发信号一旦它已退出其 PID/PGID 数字可能已被系统复用绝不再对它发信号Windows 上只接受SystemRoot、WINDIR、SystemDrive三个值一致指向的系统根目录下的taskkill.exe——任意为空或不一致就拒绝绝不从命令自己的当前目录或 PATH 里找那里是CHECK:环境可控的区域见 scripts/lib/process-tree.mjs发出了杀信号不等于进程已死检查器始终有自己兜底的有界定时器。 证据与日志成功输出不落盘命令输出可能含隐私路径或敏感文本unlazy 的处理策略是只消费、不留存成功输出只用于EXPECT:匹配然后被压缩为SHA-256 摘要 字节数写入证据原始内容不回显、不入账本失败诊断仅出现在本地终端、有界、并剥离终端控制字符dispatch 状态里只存时间戳和不透明的宿主句柄——官方明确要求不要把 prompt、凭据或结果正文塞进任何句柄。另外unlazy 本身不采集遥测、不向外发送审批/门禁/hook 状态但请记住一条CHECK:命令是任意代码它自己可以发起任何网络或日志行为——这正是CHECK 即代码的另一面。 安装器的隐私边界scripts/install-hooks.mjs 只在显式调用时修改 Claude Code 设置默认写项目本地的.claude/settings.local.json含绝对路径可能暴露本地目录名请加入 ignore 规则--shared写入的绝对路径通常不可移植协作场景慎用安装/卸载保留无关 hook新处理器带精确的管理标记不用子串匹配旧式处理器也只按精确形状识别拒绝畸形设置形状而不是直接覆盖原子写入并在替换前生成settings-file.unlazy.bak备份。✅ 新手安全检查清单把以上原理浓缩成一张可操作的清单运行继承账本前先--status解析逐条读完CHECK:、EXPECT:、CWD:和被调脚本确认 shell 解析结果--shell→UNLAZY_SHELL→ 平台默认与继承的PATH符合预期只对你写的或完全理解的命令使用--approve任何绑定项账本、命令、CWD、shell、PATH……变化后重新审批依赖脚本/fixture 变更后重新审查 跑--reverify不要批量删除.unlazy/locks下的锁文件.unlazy/、.unlazy-hook-state.json、.claude/settings.local.json加入项目 ignore不可信代码用一次性环境或更强的沙箱容器/虚拟机提交或分享账本前复查其中的证据与状态日志是否含敏感信息提交任何 Claude 设置文件前先审查 diff 发现漏洞怎么办一般缺陷走常规 issue 并附最小复现但如果复现本身会暴露密钥或构成滥用途径应优先使用仓库的私有漏洞报告通道不可用时先发一个最小 issue 请求建立私密联系渠道在渠道建立前不要包含敏感细节。完整流程见 SECURITY.md 的Reporting a vulnerability一节。unlazy 的威胁模型可以一句话总结它不假装能隔离不可信代码而是把未经审查的命令绝不执行做成了一整套精确到执行指纹的审批协议并在所有无法确定安全的路口选择拒绝。理解 CHECK 即代码、审批边界、fail-closed 这三个概念你就掌握了它全部安全设计的骨架。【免费下载链接】unlazyAnti-laziness skill for AI agents. Core: the Depth Tree method, which splits a task N layers deep and gives every leaf the full time budget of the whole task, so effort multiplies with depth. Grounded in 2025-2026 research on model laziness, underthinking and premature completion.项目地址: https://gitcode.com/gh_mirrors/unl/unlazy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考