11月12日，OpenAI把Codex Security放上了GitHub，形式是一个开源命令行工具加一套TypeScript SDK。它能做的三件事写在介绍里：审查代码库的安全问题、验证自己找到的问题、生成候选补丁。支持范围包括整仓库扫描、安全策略草拟，以及接入持续集成流水线。发布后不到一天，这个仓库就在GitHub趋势榜上累积了数十颗星并持续增长。
与发布同步上线的是0.10.0版本，改动只有三项，但每一项都指向同一件事：让这个工具在真实工程里待得住。第一项是扫描可以在中断后继续，而不是从头再来；第二项是可以给一次扫描设定成本预算，跑完之前先封顶；第三项是补丁失败时给出更清楚的诊断，让人能判断究竟是模型读错了代码，还是补丁根本打不上。
这三项都不是模型能力的提升，属于工程可用性的补齐。一个扫描器在演示视频里跑得漂亮，和在别人的仓库里跑得可靠，中间隔着的正是这类细节。跑过大型仓库的团队都遇到过一个场景：扫描进行到第四十分钟，网络断了或者额度用完了，一切归零。
0.10.0这个版本号本身也说明问题。0开头意味着接口还在变，官方没有把它包装成成熟产品，而是先放出来让社区试。开源扫描器这条路上已经有Semgrep、CodeQL这类做了很多年的工具，新来者要靠的不是覆盖率，而是"AI能不能理解上下文"这一层增量。
仓库级扫描的时间尺度与单文件检查完全不同。一个中型后端项目动辄几十万行代码，加上依赖与配置，扫描器要走完所有路径需要相当长的连续时间。如果每次中断都要重来，这个任务在流水线里就没有位置，因为流水线的每一步都有超时限制。
续跑能力的实现方式通常是把已完成的部分落盘成检查点，恢复时读取检查点跳过。听起来简单，实际要处理的是状态一致性：哪些文件在处理过程中被改动过、哪些结论依赖的上下文已经失效、哪些发现需要重新验证。这一层做不好，续跑出来的结果会混着新旧两种代码的判断。
对安全团队来说，可中断意味着可以把扫描安排在夜间低峰时段，第二天早上看报告。这个使用习惯一旦形成，工具就从"偶尔手动跑一次"变成了"每天都跑"的常规动作，价值的差别很大。
第二项改动是成本预算。这类工具的成本结构和传统静态分析完全不同：传统工具按机器时间算，AI扫描按词元算，而词元消耗与代码复杂度、发现数量、生成补丁的轮次都相关，很难事先估算。开放预算上限，等于把"这次扫描最多花多少钱"变成一个显式参数。
这个设计对采购决策的影响比技术细节更直接。企业引入一个新工具时，最常被问到的问题不是准确率多少，而是"一个月大概花多少"。没有上限的工具在财务上不可控，很难通过审批。给出预算参数之后，团队可以先设一个很小的额度试跑，看到效果再调高。
预算与续跑放在同一个版本里发布，说明设计者考虑的是同一类用户：那些要把工具长期挂在流水线上、每天跑几十次、每次都要控制成本的人。这类用户不会因为演示效果好就付费，只会因为账单可预测才留下。
第三项改动最容易被低估。生成候选补丁是这类工具的核心卖点，但补丁失败的原因有很多种：模型可能误判了漏洞的真实成因，可能改对了逻辑但破坏了接口，也可能补丁本身没问题、只是上下文已经因为别人的提交而失效。这三种情况对应的处理方式完全不同。
如果诊断信息只报告"补丁应用失败"，工程师需要自己逐行比对，成本比手写补丁还高。把失败原因分类输出，等于把排查的第一步做掉了。这个小改动决定了工具是"帮人省时间"还是"给人添活"。
从产品逻辑上看，OpenAI在这个版本里没有强调检测率提升了多少，而是集中在三件让工具"能用久"的事上。这个取舍说明它面对的不是研究评测，而是真实的安全工作流，那里没有满分，只有误报率和人力成本。一个能跑完整个仓库、中途可暂停、花多少钱事先知道的扫描器，即便漏掉几个问题，也比一个跑不完的满分工具更容易被留下。
把Codex Security放进现有的安全工具链里看，它的位置大致在静态分析与人工审计之间。静态分析跑得快、规则明确、误报多；人工审计判断准、覆盖少、成本高。AI扫描想占的是中间那段：用语义理解过滤掉大量误报，把真正需要人看的问题排到前面。
这个位置此前也有产品在争，但多数是商业闭源方案，按席位或者按扫描次数收费。OpenAI选择开源加SDK，等于把集成权交给使用者：团队可以把它挂进自己的流水线，也可以只调用SDK里的某一步，比如只用它做发现验证，补丁部分自己写。
需要清醒看待的是，开源不等于零成本。词元账单、误报带来的人工复核、以及把工具接进现有流程的工程量，都是真实支出。对中小团队来说，先在一个边缘项目上试跑，把预算上限设低，看清楚误报率再决定要不要铺开，比一次性接入主干更稳。