OpenAI Codex把Claude代码审出3个漏洞

Claude写代码、Claude自己审，相当于学生给自己批改作业——盲区永远都在。

一位开发者做了个实验：让GPT-5.4（Codex CLI）去审Claude Code写的代码。结果Codex揪出3个关键问题，而Claude自己全都没发现。

6个桥接工具都在做同一件事，只有这个不一样

GitHub上已有6个以上的Codex MCP桥接工具。它们的逻辑简单粗暴：调用codex exec，返回原始文本。Claude根本不知道Codex内部发生了什么。

claude-code-codex-agents的做法是解析完整的JSONL事件流，生成结构化报告：

执行时间8.3秒，用了3个工具，改了1个文件，Codex的响应是"修复了认证逻辑"——每一步都清晰可见。

开发者Tsunamayo7把这个工具开源，MIT协议，56个测试用例，要求Python 3.12+。安装只需两行命令：npm装Codex，git clone仓库，uv sync同步依赖，最后往Claude的settings.json里加一段配置。

最狠的测试：让GPT-5.4审它自己的桥接代码

实验的精髓在于"交叉火力"。开发者让GPT-5.4去审claude-code-codex-agents的源码——正是连接它和Claude的那套代码。

Codex找出3个关键漏洞。Claude（写这段代码的模型）一个都没发现。

不同模型，不同盲区。这句话的分量比听起来重得多。

开发者又做了并行测试：同一道题"Python最佳线程安全单例模式"，同时扔给Claude Agent和Codex。

Claude的方案里没出现lru_cache。Codex想到了。两个模型确实会产出不同的解法，这不是修辞，是实测结果。

这对写代码的人意味着什么

AI代码助手的市场格局正在微妙变化。之前是各家用自家模型，Claude用Claude，GitHub Copilot用OpenAI，互不往来。

现在有人把桥搭起来了。不是简单的API调用，是深度的事件流解析和结构化反馈。

对开发者来说，这相当于有了一个"第二意见"的自动化流程。Claude写完，Codex审一遍；或者反过来。盲区互补，而不是互相确认。

开源社区的反馈还在早期。GitHub仓库的星标数、issue讨论、实际接入的生产项目——这些数据会决定这个工具是昙花一现，还是成为新的工作流标配。

开发者Tsunamayo7的README里留了一句话："Star if useful! Feedback welcome." 没有承诺路线图，没有企业愿景，就是简单的实用主义。

这种语气本身也是一种信号。AI工具正在从"惊艳演示"走向"基础设施"，开发者更关心的是它能不能无缝塞进现有流程，而不是它用了什么酷炫技术。

Claude Code和Codex CLI都是命令行工具，目标用户重叠度极高。把它们桥接起来，本质上是在打破厂商的围墙花园。OpenAI和Anthropic都没有官方支持这种互操作，但社区自己造出了通道。

接下来的问题可能是：这种互审模式会不会成为CI/CD的默认环节？当AI代码审查AI代码成为常态，人类开发者的角色会往哪个方向收缩？

有个细节值得玩味：Codex审出的3个漏洞，具体是什么类型？原文没提。是并发安全问题，还是边界条件处理，抑或是资源泄漏？

开发者没展开。也许下一轮更新会补上。也许这就是开源项目的节奏——先跑起来，再填坑。