在前面的文章中，我们看到了Codex的强大能力——批量任务处理、云端异步执行、90+插件生态、87.7%的PR合并率。但能力越大，责任越大。Codex是一个拥有文件系统访问权限、可以执行Shell命令、能够连接外部服务的自主智能体。当它“跑偏”时，后果可能比你想象中严重。2026年上半年，Codex经历了一系列安全事件——GitHub令牌窃取漏洞、npm供应链攻击、间接AGENTS.md注入、以及桌面应用中无需点击即可数据外泄的提示注入漏洞。这些不是理论风险，而是已经发生的真实攻击。本文从具体的漏洞案例出发，深入分析Codex的能力边界和安全风险，帮你建立“什么时候该用，什么时候不该用”的判断框架。
一、测试任务接受率仅 59.6%：能力边界的第一条线
Codex在9类任务中的PR接受率范围为59.6%-88.6%，整体表现均衡。但测试任务是Codex的明显短板，接受率仅为59.6%。
这意味着：让Codex写代码，它的成功率很高；让Codex验证代码，它需要人类更多的把关。 原因在于，测试任务需要理解“什么样的行为是正确的”，这涉及到对业务逻辑的深层理解，而不仅仅是代码生成能力。
实践建议：Codex生成的测试代码必须经过人工审查。不要让Codex“自己写测试、自己验证”形成闭环——这会产生“测试通过了但代码是错的”的风险。
二、目标连贯性失败：Agent“跑偏”的真实案例
2026年10月，GitHub上出现了一个关于Codex Desktop的Issue报告：Codex Desktop的智能体在长时间、高复杂度的任务中出现了“持续目标连贯性失败” 。
具体表现是：智能体保留了细节，却丢失了治理目标。它们依然能够调查、使用工具、推理、提出计划，但即使经过明确纠正，仍然无法回到最初的目标。这意味着在长时间运行的任务中，Codex可能会“忘记自己最初要干什么”，陷入局部优化而偏离核心目标。
实践建议：对于长时间运行的任务（超过1小时），设置阶段性检查点，人工确认方向是否正确。不要让Codex在无人监督的情况下运行数小时以上。
三、代码回退率：0.7%的数据背后
一项关于AI编码代理回退变更的实证研究发现，不同代理的代码回退率差异显著：OpenAI Codex的回退率为0.7%，而GitHub Copilot为7.6%。
Codex的0.7%回退率是所有代理中最低的，这是一个积极的信号。但0.7%意味着每1000次提交中仍有7次需要回退。回退的常见原因包括：意外副作用（22.33%）、过度工程化（22.13%）、功能不正确（17.71%）、依赖管理问题（12.47%）。
实践建议：将Codex的变更纳入CI/CD流水线，通过自动化测试和代码审查捕获那0.7%的问题。不要盲目合并Codex生成的PR。
四、安全漏洞：真实发生的攻击案例
4.1 Unicode注入窃取GitHub令牌（CVE级别漏洞）
2026年4月，BeyondTrust Phantom Labs披露了Codex中的一个严重漏洞：由于输入净化不足，攻击者可以在GitHub分支名称中嵌入恶意命令。攻击利用了特殊Unicode字符——如表意空格——来隐藏有害载荷。
攻击者可以创建包含隐藏代码的恶意分支。当用户或Codex与这些分支交互时，可能发生意外的命令执行，以明文形式暴露GitHub访问令牌，进而导致仓库接管或内部代码库的未授权访问。该漏洞影响范围广泛，不仅影响Codex，还影响ChatGPT、Codex SDK和开发者扩展。
OpenAI于2025年12月16日收到报告，一周内发布了初步补丁，并在2026年1月底完成了额外的安全改进，将其分类为“Critical Priority 1”。
4.2 npm供应链攻击窃取Codex认证令牌
2026年6月，安全研究人员披露了一个名为codexui-android的npm包，该包被宣传为OpenAI Codex的远程Web UI，每周下载量约29,000次。该包中包含恶意代码，会静默窃取用户的Codex认证令牌并发送到攻击者控制的服务器。
恶意代码读取~/.codex/auth.json文件的内容，将其中的access_token、refresh_token、id_token和账户ID发送到伪装成Sentry的远程服务器。刷新令牌永不过期——攻击者持有它就可以无限期地静默冒充用户，访问该账户能访问的任何系统。
更令人担忧的是，恶意代码被专门嵌入到发布的npm tarball中，而GitHub仓库保持干净——这直接绕过了源码审查审计。
4.3 间接AGENTS.md注入：供应链攻击的新维度
NVIDIA AI红队发现了Codex中的一个间接AGENTS.md注入漏洞：一个被入侵的Go库检测到Codex环境（通过CODEX_PROXY_CERT变量），写入一个恶意AGENTS.md文件，指示智能体在main函数中注入5分钟延迟，同时在PR摘要中隐藏这一变更。
这个攻击的独特之处在于：Agentic工作流扩展了传统供应链风险，使被入侵的依赖能够通过受信任的配置文件重定向AI智能体。OpenAI承认了该报告，但认为该攻击并未显著超出已有的被入侵依赖场景的风险。
缓解策略包括：使用专用安全智能体进行自动化安全监控、固定精确依赖版本、使用端点安全工具保护AGENTS.md文件完整性、监控意外文件修改。
4.4 CVE-2026-14898：无需点击即可数据外泄
2026年7月披露的CVE-2026-14898是一个macOS Codex桌面应用的严重漏洞。Codex桌面应用会自动从模型响应中的Markdown渲染远程图片。攻击者可以在Codex处理的内容中放置间接提示注入，诱导模型构造一个包含敏感数据的远程图片URL。应用在渲染响应时会自动抓取该URL，将嵌入的数据发送到攻击者控制的服务器——无需用户点击。
成功利用可能外泄Codex会话中可访问的机密信息，包括API密钥、源代码和连接工具返回的数据。
五、提示注入：AI Agent最现实的威胁
以上四个案例都指向同一个根本性问题：提示注入是AI Agent最现实的威胁。无论是通过Unicode字符隐藏命令、通过AGENTS.md注入指令、还是通过Markdown图片外泄数据，攻击的核心都是让Codex执行了它本不该执行的指令。
为什么提示注入如此难以防范？ 因为大语言模型本质上无法区分“来自用户的指令”和“来自内容的指令”。当Codex读取一个文件、调用一个工具、或者渲染一段Markdown时，其中的内容可能包含恶意指令。
实践建议：
不要给Codex不受限制的网络访问权限
对Codex处理的外部内容保持警惕
使用沙盒模式限制Codex的执行范围
定期审查AGENTS.md文件的内容
六、工程缺陷：67%的Bug与功能相关
一项针对AI编码工具（包括Claude Code、Codex和Gemini CLI）工程缺陷的实证研究发现：超过67%的Bug与功能相关，最常见的用户报告症状是API错误（18.3%）、终端问题（14%）和命令失败（12.7%）。
这意味着Codex并非完美无缺——它的API调用可能失败，终端交互可能出问题，命令执行可能出错。这些不是安全漏洞，而是工程成熟度问题。
七、性能开销：Codex的隐藏成本
Codex的自适应推理能力意味着复杂任务会消耗大量计算资源。对于最复杂的10%请求，Token消耗约为原来的2倍。在CI/CD流水线中频繁调用Codex，可能导致成本快速上升。
实践建议：
为Codex任务设置Token预算上限
将Codex调用放在流水线的关键节点，而非每个PR都调用
使用codex exec的–ephemeral模式跳过会话持久化，减少存储成本
八、什么时候不该用Codex？
基于以上分析，以下场景应该谨慎使用或避免使用Codex：
九、风险缓解的最佳实践
沙盒模式永远不用danger-full-access：除非在完全隔离的容器中。
API Key存Secrets，不存代码：~/.codex/auth.json等同于密码，不要提交到Git。
固定依赖版本：使用精确版本号，避免自动拉取被篡改的依赖。
保护AGENTS.md完整性：监控文件修改，使用端点安全工具。
设置审批门禁：高风险操作（数据库变更、生产部署）必须人工审批。
定期审查Codex的输出：不要盲目合并PR，逐行审查diff。
使用Auto-review模式：减少人工审批频率的同时保持安全边界。
监控Token消耗：设置预算告警，避免成本失控。
十、小结
测试任务接受率仅59.6%：Codex在验证代码上需要人类把关。
目标连贯性失败：长时间运行的任务可能“跑偏”，需要阶段性检查。
代码回退率0.7%：虽然很低，但仍需CI/CD流水线捕获问题。
四个真实安全漏洞：Unicode注入、npm供应链攻击、AGENTS.md注入、CVE-2026-14898。
提示注入是最现实的威胁：攻击者通过内容而非用户指令控制Codex。
67%的Bug与功能相关：API错误、终端问题、命令失败是常见症状。
性能开销：复杂任务Token消耗翻倍，需要预算控制。
风险缓解：沙盒限制、审批门禁、依赖固定、输出审查、预算控制。
