openai/codex/
├── codex-rs/                  # Rust 主代码库（约 95.6%）
│   ├── core/                  # Agent Loop / Session / TurnContext / 上下文管理
│   ├── tui/ 与 tui2/          # 终端 UI
│   ├── protocol/              # Op / Event 枚举，客户端与服务端共享
│   ├── mcp/                   # MCP client 与工具调度
│   ├── exec/                  # 非交互 headless 模式（CI 用）
│   ├── app-server/            # JSON-RPC over stdio，IDE 集成入口
│   ├── sandbox/               # Seatbelt / Landlock / Job Objects 策略
│   └── apply-patch/           # 把 LLM 输出 patch 应用到文件系统
├── codex-cli/                 # 遗留 TypeScript CLI（维护状态）
├── sdk/                       # TypeScript SDK
└── AGENTS.md                  # 项目自身的 Agent 指令（Rust 开发规范）

Codex CLI (AI IDE Platform Market Research)

1. Introduction

Codex CLI is OpenAI's open-source coding agent tool, and among the six platforms in this group it is the only one that open-sources its sandbox and approval mechanisms in full. It was first released as open source in TypeScript on 2025-04-17; on 2025-05-30 it announced a rewrite in Rust that was completed quickly, with the TypeScript version entering maintenance status; from 2025-05-16 the bundled cloud Codex (research preview) added internet access, task tracking and change review, and opened to ChatGPT Pro / Enterprise / Team users in June of the same year.

Its distinctive value lies not in any single capability but in transparency: how the sandbox is built, how approval is divided, and how configuration takes effect all live in readable source code and configuration files. For those studying AI Harness, Codex CLI is the reference implementation for L2 (tools and execution) and L6 (governance and security) — this group's README comparison matrix rates it as "sandbox + approval orthogonal + configuration as policy", and these three things form the main thread of this article.

1.1. Developer and Product History

1.2. Positioning and Latest Version

Codex CLI is positioned as an open-source, terminal-first coding agent built on a skeleton of sandbox and approval. It differs from Claude Code in three ways: first, it is open source (Apache 2.0), so the execution stack is auditable and can be built by anyone; second, its permission model is an explicit two-dimensional design — "the sandbox governs what can technically be touched, approval governs when to stop and ask"; third, multiple interfaces share the same core, with the CLI, VS Code extension, desktop and Web endpoints all reusing the same Codex Core via the same app-server protocol.

The 2026-09 version line (official Changelog basis, cross-checked against a third-party aggregation, Grade B): GPT-6 Astra has been Codex's default model since v0.153.4; 0.154.0 (09-09) added GPT-6 Astra to the model selector and made it available on Amazon Bedrock, with new experimental worktree support and mid-task inline questioning; /plugins divides remote plugins into three zones — OpenAI Curated / Workspace / Shared-with-me — and can proactively recommend installation mid-turn; a configurable rollout token budget was introduced — tracking spend across agent threads, reminding on remaining quota and aborting the turn when exhausted. The earlier anchor in the tag sequence is rust-v0.150.x (2026-08).

1.3. Pricing Model

Codex CLI itself is free and open source; usage is charged to an OpenAI paid plan:

Engineering implications of the billing structure: as with Claude Code, the subscription model makes long-task costs predictable, and runaway agent loops do not produce surprise bills; this is the cost advantage of terminal-based tools in CI and batch scenarios.

---

2. Glossary

---

3. Feature Overview

3.1. Interaction Modes

3.2. Sandbox and Approval Capabilities

Codex CLI's permission model consists of two independent knobs, and this design is the core of this article; see the full breakdown in 5.2 and 5.6. The summary is as follows:

• sandbox_mode: read-only (read-only), workspace-write (only the workspace is writable, network off by default), danger-full-access (no isolation).
• approval_policy: untrusted (deny by default and request approval), on-request (the agent can request privilege escalation as needed), never (never interrupt).
• The early three-tier approval modes --suggest / --auto-edit / --full-auto were replaced from 2026-04 by a mechanism of profiles plus an explicit trust prompt, and the old flags are explicitly deprecated.

3.3. Extension and Integration Capabilities

• MCP: configured in the mcp_servers section of ~/.codex/config.toml (TOML format); from 2026 tool search is enabled by default, so tool definitions of large MCP servers are no longer fully loaded into context; codex mcp can expose Codex itself as an MCP server for other agents to call.
• Multi-agent: the MultiAgentV2 configuration provides thread limits, depth and wait-time controls, and separation of root / subagent prompts.
• Persistent goals: /goal persists long-term goals to the app-server, which can be created, paused, resumed and cleaned up.
• Desktop: can autonomously operate macOS desktop applications (independent cursor, viewing the screen, clicking, typing), has a built-in browser, newly added memory (saving preferences, common workflows and tech stacks), and can autonomously schedule work plans ranging from days to weeks ahead (third-party report).
• Self-update and plugins: codex update self-updates; plugin marketplace, remote plugin caching and hook switches.

---

4. Platform Architecture

图 4-1｜Codex CLI 平台总体架构：多界面共享单一核心，沙箱为独立可替换层

数据来源：基于本文分析绘制的示意图。

4.1. Overall Architecture

Repository structure and the three-layer essence (third-party analysis of the open-source code, consistent with the official repository structure):

openai/codex/
├── codex-rs/                  # Rust 主代码库（约 95.6%）
│   ├── core/                  # Agent Loop / Session / TurnContext / 上下文管理
│   ├── tui/ 与 tui2/          # 终端 UI
│   ├── protocol/              # Op / Event 枚举，客户端与服务端共享
│   ├── mcp/                   # MCP client 与工具调度
│   ├── exec/                  # 非交互 headless 模式（CI 用）
│   ├── app-server/            # JSON-RPC over stdio，IDE 集成入口
│   ├── sandbox/               # Seatbelt / Landlock / Job Objects 策略
│   └── apply-patch/           # 把 LLM 输出 patch 应用到文件系统
├── codex-cli/                 # 遗留 TypeScript CLI（维护状态）
├── sdk/                       # TypeScript SDK
└── AGENTS.md                  # 项目自身的 Agent 指令（Rust 开发规范）

The key engineering judgment is the "three-layer essence": model layer + host layer (Harness) + sandbox layer. Codex CLI draws the boundary between the host layer and the sandbox layer extremely clearly — core/ and sandbox/ are two independent modules, and permissions are not scattered if-statements here and there but an independent, replaceable layer.

4.2. Operating-System-Level Sandbox Binding

Known boundary in container environments: in a Docker container, if the host or container configuration does not support Landlock / seccomp, the sandbox may fail. In that case the official recommendation is for the container itself to provide isolation guarantees and then run inside it with danger-full-access or --dangerously-bypass-approvals-and-sandbox — this is a textbook statement of the principle that "unattended operation must explicitly declare its trust boundary": giving up the sandbox must be a decision explicitly written into the configuration and command line, not a silent downgrade.

System requirements: macOS 12+, Ubuntu 20.04+ / Debian 10+, Windows 11 via WSL2; 4 GB RAM minimum (8 GB recommended).

4.3. Multi-Interface Consistency Architecture

app-server exposes Codex Core to upper layers over JSON-RPC over stdio, so the CLI, VS Code extension, desktop and Web endpoints share the same set of sessions, configuration and sandbox policies. The engineering implication is the opposite of Cursor's dual-runtime problem: Codex, through "a single core + protocol distribution", avoids the split where "it runs well locally but runs wrong in the IDE" — there is only one copy of policy and state; the interface is just a view.

---

5. Harness Design

5.1. L1 Context Engineering Layer

AGENTS.md discovery and merge order (per the official documentation):

1. Global scope: read AGENTS.override.md first under ~/.codex (or $CODEX_HOME); otherwise read AGENTS.md; this layer only takes the first non-empty file.
2. Project scope: from the Git root walk downward to the current working directory, checking AGENTS.override.md in each directory, then AGENTS.md.
3. Merge order: global (personal preference) → repository root (team-shared) → current directory (submodule conventions); the closer to the current directory, the more specific the instructions.

Two designs worth noting:

• The existence of AGENTS.override.md means a team can explicitly override shared instructions for a particular machine or environment without modifying files under version control — this is the landing point of "separation of personalization and sharing" at the instruction layer.
• /init generates an initial AGENTS.md, writing in test commands, style rules and working conventions such as "do not touch the migrations directory", which lowers cold-start costs.

Model parameters such as model_reasoning_effort in config.toml also belong to context management in a broad sense: the reasoning tier determines the depth of thinking and token consumption per unit task, and together with the rules files decides "how much context budget each task spends".

5.2. L2 Tool and Execution Layer (Focus of This Platform)

Sandbox mode (sandbox_mode) — "what can technically be touched":

Approval policy (approval_policy) — "when to stop and ask":

Historical approval modes (per the 2025 TypeScript version, now superseded by the current configuration model):

The evolution across all three levels points in the same direction: from "a one-dimensional tiering by action type" toward "a two-dimensional orthogonality of sandbox × approval". The defect of one-dimensional tiering is that it bundles "modify files", "run commands" and "touch the network" into a single tier even though the three differ entirely in risk profile; the two-dimensional model lets teams configure "what can be touched" and "when to ask" independently — this is Codex CLI's most valuable contribution for similar products.

5.3. L3 Orchestration and Control Layer

Codex's L3 orientation is "give orchestration to configuration and protocol, not to the interface": codex exec lets any CI system become the orchestrator, while /goal and MultiAgentV2 provide minimal but explicit built-in orchestration primitives. Compared with editor-style tools, it lacks a visual kanban, but in exchange it is scriptable and versionable — the orchestration policy itself can go into git.

5.4. L4 Memory and State Layer

L4's orientation is "file-based, session-assisted": cross-session memory uses AGENTS.md as the authoritative source, session resume handles temporary continuity, and desktop memory is still early. This converges with Anthropic's conclusion of "externalizing state into files and version history".

5.5. L5 Evaluation and Observability Layer

Note: SWE-bench Verified was officially deprecated by OpenAI on 2026-02-23 (because ≥59.4% of the defect tests have gold patches reproducible by all frontier models); the scores cited are the historical figures before deprecation. See 02-行业赋能/03-软件工程组/06-benchmark.md.

/status is an easily underestimated L5 design: the observability of governance configuration is as important as governance itself. If users cannot cheaply confirm "whether the sandbox is really on", then the sandbox's actual line of defense depends on luck.

Official enterprise-grade quantitative case: none was obtained in this search; marked "no result".

5.6. L6 Governance and Security Layer (Focus of This Platform)

Codex CLI's L6 is the most complete reference implementation in the open-source ecosystem; its core consists of four principles:

1. Sandbox × approval orthogonality (see 5.2). Both the official documents and the community repeatedly stress that the two knobs must be read in pairs: never + read-only is entirely reasonable for research tasks (nothing can be damaged); never + danger-full-access is an unattended agent with root-level reach over the host. Looking at either knob alone is meaningless; risk only shows itself in the combination.
2. Network off by default. Under workspace-write, network_access = false is the setting most worth keeping — dependency installation must become an explicit decision to avoid supply-chain attacks in unattended runs. This mutually confirms the "filesystem isolation and network isolation are both indispensable" point raised in this group's README.
3. Guardian subagent (2026-04): the guardian subagent reviews actions to be executed rather than approving them blindly, directly responding to the risk of "an agent executing destructive commands unattended". Notably, it delegates part of the L6 decision to a second model instance — using an agent to review agents, whose reliability depends on the robustness of the reviewing model itself.
4. Configuration as policy: profiles unify and name the sandbox, approval, model and MCP states; project-level .codex/config.toml lets repository teams fix a security baseline and review it with git. The deprecation of the old --full-auto is precisely to close the "one-click enablement that bypasses the configuration system" path. On filesystem permissions, from 0.131 / 0.132 deny became the normative standard for filesystem permissions.
5. Budget guardrails (2026-09): the rollout token budget brings "task- and tenant-level budget caps + circuit breaking" into the CLI itself — unified accounting across agent threads, headroom reminders and turn abort on exhaustion. This is the single-machine-tool-side engineering response to the L6 cost-runaway risk (see whitepaper 07-治理与风险 §4.7): budgeting is no longer a capability exclusive to platform-managed runtimes, but ships with the open-source execution stack.

Response to the L6 cautionary example: the attack surface exposed by the Amazon Q incident (2025-08-11, prompt injection inducing deletion of AWS resources) maps in Codex's model to — under the never + workspace-write tier, an injected instruction can do whatever it wants inside the sandbox (write files, write malicious scripts); although turning the network off blocks exfiltration, a "malicious script awaiting human execution" can still take effect through subsequent human operations. Conclusion: the sandbox constrains the execution domain, not semantics — unattended use of a high-risk tier should be paired with one-off containers and a full post-hoc diff review.

5.7. Summary of the Six Layers

---

6. Practical Cases

Note: as of the time of writing, no enterprise adoption case with quantitative metrics published by OpenAI was found; the following cases are reproducible workflows from the official cookbook and public reports, and every quantitative figure has been tagged with its source level.

Case 1: Legacy system modernization. The official cookbook provides a complete COBOL → modern stack case: use a read-only sandbox to have Codex first read through and explain the legacy code, then rewrite it progressively inside a workspace-write sandbox, with each step's changes written to disk as patches and reviewed by a human. The reusable structure of this case is "read with the read-only tier, write with the workspace tier", aligning the approval tier with the task phase.

Case 2: CI automatic review. Use codex exec to take on PR-triggered automatic review: when a PR enters review, CI runs Codex with approval_policy = "never" + a read-only sandbox, producing review comments without touching the code. This is the minimal landing point of the L2 + L6 combination in a workflow: non-interactive, read-only, auditable.

Case 3: Overnight batch refactoring. A team runs codex exec inside a one-off container, where the container itself provides the isolation guarantee (see the container boundary in 4.2); Codex executes freely inside the container with danger-full-access + never, the task output is returned as a branch and diff, and a human only reviews the final diff. The blast radius is contained by the one-off container, making it the only officially recognized way to use the high-risk tier.

Case 4: Scale figures (marketing-oriented). In 2026-04 OpenAI announced Codex as "a companion to over 3 million developers" (reproduced from the official source statistical basis). Third-party engineering analysis on the repository side shows 10,000+ commits, 640+ releases and a peak cadence of 3–4 releases per day, which indirectly corroborates its iteration intensity; these are all third-party statistics ().

---

7. Summary

7.1. Strengths

1. An open-source reference implementation for L6: the two-dimensional sandbox × approval model, the three OS-level sandboxes and configuration-as-policy are all open source and auditable, making it the most transparent governance design among similar products.
2. Zero-dependency execution stack: the Rust rewrite delivers a single-binary install, giving the lowest integration cost for CI and constrained environments.
3. Multi-interface consistency: the app-server protocol lets CLI / IDE / desktop / Web share the same core and the same policy.
4. High token efficiency: third-party evaluations generally find it consumes less on equivalent tasks than some closed-source competitors (), friendly to usage-based billing and batch workloads.
5. Permissions as a first-class citizen: /status makes governance configuration observable, deny became the normative standard for filesystem permissions, and permissions are not tied to the interface.

7.2. Limitations

1. Long-chain autonomous planning is weaker than some closed-source competitors: third-party evaluations point out that tasks beyond 3–4 steps may lose direction (); complex long tasks need decomposition or pairing with /goal.
2. Single model binding: strongly dependent on OpenAI models and the Responses API; not suited to fully offline or cross-model comparison scenarios.
3. Enterprise capabilities must be self-built: RBAC, audit logs, multi-tenancy and organization-level policy distribution are all outside the CLI's scope and must be wrapped by the team.
4. No checkpoint mechanism: rollback after errors relies on git and manual operations, so L4 completeness is lower than editor-style tools.
5. Single-crate complexity pressure: the official AGENTS.md declares that "codex-core crate is bloated, resist adding code to codex-core", and the maintenance cost of the core module is rising.

7.3. Applicability Boundary

7.4. Selection Recommendation

The criteria for choosing Codex CLI are: tasks are primarily scripted, batched and CI-oriented, and the team needs governance mechanisms that are readable, auditable and modifiable. It is the only tool in this group whose "how the sandbox isolates and how approval is triggered" can be read down to the source-code level — for teams designing their own Harness, its configuration system (config.toml + profiles + two-dimensional permissions) is worth borrowing directly.

Whether or not it is selected, this group recommends copying its three governance practices: network off by default, dependency installation made explicit; giving up the sandbox must be an explicit declaration (rather than a silent downgrade); use self-check commands such as /status to make governance configuration observable. The migration cost of these three is extremely low, while the benefit covers all agent tools.

---

Information Gap Declaration

1. Current latest version number: anchored to the GitHub rust-v0.150.x tag sequence (2026-08); the current stable version is marked [To be filled].
2. Pricing and quota details: the Codex usage quotas included in each ChatGPT tier are not fully stated on the official pages found in the search, marked [To be verified].
3. Default model and benchmark scores: the GPT-5.6 family and SWE-bench Verified 77.3%, Terminal-Bench ~62% all come from third-party reports, marked [To be verified].
4. The capability boundary of desktop memory and autonomous scheduling: from third-party retelling, marked [To be verified].
5. Enterprise deployment effectiveness data: no first-hand enterprise case with quantitative metrics was found; this article does not use any unverified quantitative effectiveness figures.
6. The trigger conditions and coverage of the guardian subagent: behavioral details beyond the official changelog are marked [To be verified].

---

8. References

1. openai/codex official repository (including AGENTS.md and the sandbox implementation) — OpenAI, 2025—2026. https://github.com/openai/codex
2. OpenAI Codex official documentation — OpenAI, 2026. https://developers.openai.com/codex/
3. Introducing Codex (cloud research preview announcement) — OpenAI, 2025-05-16. https://openai.com/index/introducing-codex/
4. Harness engineering: leveraging Codex in an agent-first world — OpenAI, 2026-02-11. https://openai.com/index/harness-engineering/
5. OpenAI API documentation · Responses API — OpenAI, 2025—2026. https://platform.openai.com/docs/guides/responses
6. Landlock kernel documentation (Linux kernel userspace API) — Linux Kernel Organization, 2024—2026. https://docs.kernel.org/userspace-api/landlock.html
7. Model Context Protocol official site — MCP / AAIF, 2024—2026. https://modelcontextprotocol.io/
8. SWE-bench official site — Princeton / community, 2023—2026. https://www.swebench.com/
9. Terminal-Bench official site — Stanford / Laude Institute, 2025—2026. https://www.tbench.ai/
10. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-30. https://survey.stackoverflow.co/2025/
11. DORA 2025 State of AI-assisted Software Development — Google Cloud / DORA, 2025. https://dora.dev/
12. Effective context engineering for AI agents — Anthropic, 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents