你的CI里跑着一个“默认开放一切”的编码代理，还是在用“先拒绝再证明”的偏执狂？如果你受够了臃肿的下载包，也厌倦了把命令失败误当成权限问题排查到深夜，那gitlawb-zero正在逼近的0.4.0版本，大概会踩中你的舒适点。从提交流看，这个项目在同一时间窗口里把分发方式和安全边界都打磨了一遍——并不是随便修修bug，而是重新校准了“怎么把工具交到你手上”和“工具在系统里能干什么”这两件事。

先看最被用户吐槽的下载环节。一个合并的PR把原生二进制文件以npm平台可选依赖（optionalDependencies）的方式分发出去。别急着跳过这个听起来很干的概念：它是专门给那些需要为不同操作系统和CPU架构分别编译的工具准备的正确姿势。以前很多工具会把所有平台的二进制都塞进一个包，你明明在Windows上干活，却还要被迫下载macOS和Linux的版本，安装慢不说，包体积也大得离谱，更吓人的是万一哪个平台的二进制被篡改，它就堂而皇之地躺在你的本地没被用到却风险满满。而现在npm会根据你的操作系统和架构，只拉取对应的那份二进制，安装更快、占用更少，再也不会看到“咦，我Windows机器上为什么躺着一个Linux ELF文件”这种怪事。对一个主打安全的编码代理来说，这样干净的分发链条本身就堵住了一条恶意二进制顺路搭车的通道——少下来的，不只是几百兆磁盘空间，而是一整面暴露面。

沙箱这边同样有两笔提交值得细看。一笔专门针对Windows上静默包装的命令失败进行了重新分类：过去这类失败会被错误标记为“被沙箱拒绝”，让开发者误以为权限策略在阻挠，花半天检查发现只是命令自己挂了。现在这一误诊被修正，失败的归失败，被拦截的归拦截，不会再张冠李戴——这跟我们之前在Hermes的评测里揪出的问题一模一样。另一笔提交在没有配置DenyRead路径时，自动应用WRITE_RESTRICTED令牌，把默认的写入姿态从“全开”收紧为“限制写”。两笔改动合在一起，表明项目对最小特权的玩法是认真的，不是嘴上说说。它的默认策略就是：没明确允许的写入，先拒绝；就算允许了，也尽可能在受限的边界内执行。这听上去有些偏执，但对于一个要深度介入DevSecOps工作流的代理，恰恰是比“先跑起来再说”更负责任的态度。

还有一个让团队使用者眼前一亮的增量：一份公开议题和对应的PR带来了对GitHub Copilot提供商和认证的支持。这意味着gitlawb-zero的角色从只能用自家模型后端，扩展成一个可以指向Copilot的路由器——如果你的团队已经在为Copilot席位付费，现在可以直接把这个代理接上去，并在Copilot的基础上叠加扫描、防护、约束等DevSecOps流程，而不必再单独拉一条模型后端的账。对于已经建立了付费关系的组织，这种扩展就是把安全能力挂在现有投入上，降低了再采购的门槛。

回过头看gitlawb-zero的站位，它从来没有单纯盯着“让代理跑得更快”去做优化。它的视角始终是DevSecOps——在编码代理执行动作前先扫描、先守护、先约束，而不是加速完之后再追着打补丁。关于这个工具的深度解读已经详细拆解过其架构，而0.4.0这一批更新就是它还在迈步的实证。如果你的取舍是“默认拒绝并证明无害”，而不是“默认放行并祈祷别出事”，那么这个分支正是你该跟进的。顺便提一嘴，Hermes的安全文章是不错的伴侣读物，它会让你明白为什么提供者隔离与沙箱诚实性其实是同一场战斗。