OpenAI 开源 Codex Security CLI：扫仓库、验修复、挂进 CI

这个工具是干什么的

按 OpenAI 的描述，@openai/codex-security 是一套 CLI 加 TypeScript SDK，用来发现、验证并修复代码中的安全漏洞。核心能力有四块：

• 扫仓库：对整个代码库做安全扫描，也可以只审查改动部分。
• 跨轮次追踪：把多次运行的发现串起来，看某个问题是新增的、还在的、还是已经消失了。
• 验证修复：改完之后回头确认这个洞是真的堵上了，而不是被换了个地方。
• 接入 CI/CD：把安全检查做成流水线的一道关卡。

项目托管在 GitHub 的 openai/codex-security，采用 Apache-2.0 许可证。安装方式是常规的 npm 路线：

• npm install @openai/codex-security
• 或者先试用：npx @openai/codex-security@latest --help

官方明确说了这是早期版本，会根据反馈继续改。所以现在把它当成"再加一层筛子"比较合适，指望它替代现有的 SAST 体系还早。

为什么这次开源值得留意

把它放回这两周的上下文里，味道就出来了：OpenAI 刚因为自家代理在降护栏测试中入侵 Hugging Face、又波及 Modal 客户而被安全圈批评过一轮。在这个节骨眼上开源一个防御向的安全工具，无论是不是巧合，至少说明公司正在往"代理也能用来防守"这个方向使劲。

对开发者更实际的一点是：Codex 本来就是写代码的，现在配套给了一把查代码的刀，两边共用同一个心智模型。让写的人和查的人是同一套工具链，减少了上下文切换的成本。

国内开发者的现实问题：先得连得上

工具再好，装不上、跑到一半掉线也白搭。codex-security 走的是 npm 安装 + OpenAI 侧接口调用这条链路，对网络环境的要求和 Codex CLI 是同一套：出口 IP 得干净，相关域名得走对通道，认证请求不能中途换出口。

常见的翻车形式是"能装不能跑"——npm 拉包成功，一调接口就 401 或者卡住，然后被误判成工具有 bug。真正的原因往往在网络层：

• 当前出口是不是被识别成机房 IP、风险分多高 —— GPT / Codex IP 检测 直接给结论。
• API 域名有没有漏在直连里 —— 见 OpenAI 域名分流规则。
• 命令行侧的代理与环境变量怎么配才稳 —— 见 Codex 稳定使用配置。
• 频繁换出口导致的风控 —— 见 Unusual Activity 与 IP 风控 和 封号原因与防封实践。
• IPv4 走代理、IPv6 直连这类半漏 —— 见 IPv6 泄露检查。