Codex 让写代码变快了，但“快”本身正在成为新的攻击面。Veracode 2025 年的一份报告测试了 1600 余个由 Codex 等模型生成的代码样本，平均 45% 包含安全漏洞，涵盖 SQL 注入、XSS、输入校验缺失等 OWASP 典型问题。问题不在于模型“偶尔出错”，而在于这些错误是系统性、可预测的。

第一类雷区藏在代码本身。 CSDN 上的一篇实测对 Codex 生成的多语言代码做了静态分析，发现了一个清晰的模式：当提示词要求“实现用户查询”时，超过半数的输出直接拼接字符串构造 SQL；当需求涉及系统命令调用时，模型频繁使用 os.system 或 exec 而不做白名单校验；文件操作中，用户可控的文件名普遍未经路径规范化，目录穿越风险几乎成为默认行为。硬编码密钥更是实测中出现频率最高的缺陷——模型为了“让示例跑起来”，会把 API 密钥和数据库口令直接写进源码。这些问题的根源不在模型“不会写安全代码”，而在于训练数据中不安全写法本身占多数，模型默认输出的是最“常见”的方案，不是最安全的方案。

第二类雷区在工具链自身。 2026 年 8 月，研究人员披露了 Codex 的两个沙箱逃逸漏洞：Heapjack 利用 Codex Desktop 中受信与不受信 JavaScript 上下文之间的共享堆，攻击者只需让 Codex 分析一个恶意仓库，就能窃取授权令牌并在宿主机上执行命令，即使处于最严格的只读沙箱模式，用户也不会看到任何审批提示；Overpatch 则滥用 CLI 的 apply_patch 工具，通过符号链接将写入权限延伸到家目录，下次打开终端时代码即被执行。Codex 通常安装在持有源代码、云凭证和签名材料的开发工作站上，一次沙箱逃逸就等于直接进入组织的软件开发环境。

第三类雷区更为隐蔽：供应链。 大模型会“编造”看起来合理的包名。研究发现，主流 LLM 生成代码中约 20% 引用了不存在的包，而这些幻觉包名具有高度可预测性——不同模型会稳定地编出同一批不存在名称。攻击者只需批量收集这些名称并抢先注册到 PyPI 或 npm，模型下次生成同样的 pip install 命令时，就会把恶意包送入开发环境和 CI 流水线。这种攻击被称为 slopsquatting：它赌的不是人手滑，而是模型会稳定地“编包名”。更麻烦的是，在 Agentic Coding 模式下，AI Agent 自主选择依赖、自动执行安装，开发者不再参与决策，攻击者甚至不需要欺骗人类，只需利用模型本身的生成偏差。

Codex 不是不能用，但不能把它当作可信的“资深工程师”。更准确的定位是：一个速度极快、安全基线不稳定的初级工程师。对应的纪律至少包括三条：提示词中显式写入安全约束和依赖白名单，让模型在受控集合内选择；生成即扫描，把 SAST 和依赖校验左移到代码写下的那一刻，而不是等到 Review 或上线；对 AI 引入的每一个新包做存在性与发布历史校验，禁止公网未审批依赖直接进入构建。

效率的红利是真实的，但安全债同样真实。Codex 的陷阱不在于它“不会写代码”，而在于它写出的代码看起来太正常了，正常到让人忘记问一句：它引用的那个包，真的存在吗？