读懂 Codex

从 token 生成、指令遵循和上下文讲到工具、反馈循环、Coding Agent、Runtime 与安全边界。

从 Codex 的实现出发，区分模型内部的下一 Token 生成与客户端 Runtime，解释有效上下文窗口、服务端 Usage、本地尾部估算、自动压缩阈值和剩余比例。

从 Codex 的实际实现出发，解释 Base Instructions、Developer 与 Contextual User 的编译、Responses Lite 适配、assistant phase 和历史回放。

从 ToolSpec、ResponseItem、SSE 完整项、call_id、ToolRouter 与 Registry 拆解 Codex 如何把模型输出变成可验证的工具调用意图。

追踪 Codex 如何先记录 Tool Call，通过并发门与取消边界执行，再按 call_id 回灌 Tool Result 并启动后续采样。

从 Codex run_turn 的真实异步控制流抽象 Preparing、Sampling、JoiningTools、Compacting、StopGate 与三类终态。

按恢复所有权拆解 Responses 重试、RespondToModel、Fatal、沙箱升级、Cancellation 与 Turn 终态，防止不安全重放。

从项目与环境快照、编码工具、权限沙箱、真实结果与 Turn Diff、验证能力、持久化恢复和扩展接口拆解 Coding Agent 的 Runtime 增量。

沿一次完整任务拆解 Codex 的执行链路：客户端协议、Session、Turn、模型采样、工具回灌、事件输出与失败处理。

Codex 的 CLI、TUI、Exec 与 App Server 如何从同一二进制分派到不同进程入口，并建立各自的协议和生命周期边界。

Codex 如何合并配置文件、Profile、命令行覆盖、环境与受管配置，并在冲突时保持安全约束的优先级。

Feature Gate 如何从默认值、配置与模型能力得到有效开关，并决定 Codex 实际进入哪条 Runtime 分支。

ThreadManager 如何创建、恢复、派生、注册和移除 CodexThread，以及并发发布和失败清理怎样保持注册表一致。

CodexThread 的提交队列、事件队列与状态 watch 如何分工，为什么提交成功不等于 Turn 完成。

Session 初始化如何并行建立服务、在 SessionConfigured 前形成可观察屏障，并用 guard 处理半初始化失败。

Codex Core 的 Op 如何按控制、Turn、设置与回答分类，由谁拥有并在 Submission 主循环中分派。

ResponseItem、Core EventMsg、App Server ThreadItem 与 UI 事件如何分层，Raw Response Item 又为什么不等于原始 SSE 字节。

普通 User Turn 如何从 UserInput 进入 RegularTask、run_turn、多次模型采样和唯一终态。

一个工具调用如何被解析、持久化、并发门控、执行、配对回写并触发下一次模型采样。

Compact、Review、UserShell 与 Rollback 为什么不能都塞进普通 Agent Loop，它们各自拥有怎样的状态与生命周期。

TUI 如何把输入、快捷键和审批动作逐层翻译为 AppCommand、App Server 请求与 Core 操作，并处理 start/steer 竞态。

App Server 如何桥接 JSON-RPC 与 Core，区分立即响应、延迟响应、通知和服务端反向请求。

Exec Server 如何抽象本地与远程执行环境，并通过握手、Session 恢复、序列事件和幂等写入管理进程。

拆解 Codex 的运行时生命周期：Thread 与 Session 的所有权、TurnContext 与 StepContext 的快照边界、Steer、Task 策略以及协作式取消。

Thread、Session 和兼容 conversation_id 的身份边界，以及新建、恢复和子 Agent 如何选择 ThreadId 与 SessionId。

ThreadManager 如何发布、查询、移除和有界关闭 live Thread，并区分 Arc 存活、注册表可见性与冷存储。

CodexThread 的有界提交、无界事件、Watch 状态与共享终止 Future 如何组成可等待的关闭协议。

SessionServices、SessionState、ActiveTurn 与 TurnState 如何划分长期服务、跨 Turn 状态和当前任务状态。

Session 输入主循环如何串行分派 Op，同时让 Turn、审批、刷新和中断在独立执行轴上协作。

Submission、Turn、Item、Call 与 Process ID 的生成者、作用域和相关关系。

SessionTask 策略、AnySessionTask 适配器和 Tokio 任务如何统一包装 Regular、Review、Compact 与 UserShell。

普通用户输入如何创建或 Steer RegularTask，以及预热、TurnStarted 和完成竞态如何进入 run_turn。

TurnContext 的字段来源、配置事务、冻结边界，以及哪些运行期记录仍可更新。

StepContext 如何把环境、AGENTS.md、MCP 工具和 ToolRouter 固定在同一次模型请求视图中。

环境 selection 如何解析为 Starting 或 Ready 快照，并在 Turn 内只刷新 readiness、不漂移选择。

run_turn 的准备、重复采样与返回阶段，以及它和采样重试、Task 终态之间的职责边界。

工具、end_turn、pending input、Mailbox、Stop Hook 与 Token rollover 如何共同决定下一次模型采样。

ResponseItem 从流式 Added/Done 到工具 future、普通 TurnItem、可恢复错误和结束判断的控制流。

InputQueue 如何协调 Turn pending input、Session mailbox、交付 phase 和完成边界输入。

Steer 如何原子校验活动 Turn，在下一采样边界生效，并用 expected Turn ID 避免误投。

Interrupt 如何先摘除 ActiveTurn，再传播到模型流、工具运行时和子进程收尾。

CancellationToken 的协作取消树、100ms 宽限和 Tokio handle 强制 abort 如何配合。

Turn、Interrupt 与 Session Shutdown 的不同清理等级，以及进程、Realtime、MCP 和持久化关闭顺序。

正常完成与中断如何通过 ActiveTurn 所有权竞争，保证每个 Turn 恰好一个公开终态。

普通完成的两道 Rollout Flush 与中断路径的三道屏障如何保证终态可重读。

Realtime、Review 和普通 Turn 在执行体、输入协议、模型通道、事件和终止语义上的差异。

拆解 Codex 的上下文编译系统：结构化 Prompt、Base Instructions、有类型的 History、Step 级 World State、AGENTS.md 作用域、差异注入与发送前规范化。

BaseInstructions 是一次模型请求的顶层指令，不是 History 中的一条普通消息。Session 创建时只选择一次基础值，后续采样从 SessionConfiguration 读取；这条独立通道让恢复会话可以继续沿用原来的行为基线。

Codex 不靠字符串出现顺序模拟指令优先级，而是保留 developer 与 user 角色。Developer Instructions 描述运行方施加的工作规则；User Instructions 和实际任务描述用户目标。两者可以同处 History，却不能在合并时跨角色折叠。

AGENTS.md 发现不是从 cwd 无限向上搜索。算法先用项目根标记确定边界，再从根到当前目录逐层查找规则文件；找不到根标记时只检查当前目录。这个边界同时决定“能看到哪些规则”和“绝不能越过哪里”。

嵌套规则采用“根规则先出现、局部规则后出现”的分层模型。Codex 不在 Runtime 内解释每条自然语言规则谁覆盖谁，而是保留来源路径和稳定顺序，让更靠近 cwd 的说明在模型输入中位于后部，并在作用域变化时整体替换当前项目规则快照。

ContextualUserFragment 是 Runtime 注入上下文的统一协议：每个实现声明角色、正文、起止标记，以及是否必须独立成一条消息。它解决的不是排版问题，而是“这段模型可见文本以后还能否被准确识别、替换和迁移”。

初始上下文是 Runtime 在新上下文窗口中建立的“模型视图基线”。它包含 Developer Instructions、Skills 元数据、扩展贡献、完整 World State 和部分窗口元数据；普通用户消息只记录一个真实输入事件。两者即使都表现为 ResponseItem:…

World State 把“模型当前应知道的事实”拆成有稳定 ID 的分区。每个分区独立定义紧凑 Snapshot 和差异渲染；整个 Snapshot 则用 JSON 对象持久化，并用 RFC 7386 Merge Patch 推进基线。模型读自然语言片段，Rollout 记结构化状…

Environment Context 不是启动时读取一次的本机信息，而是从当前 TurnEnvironmentSnapshot 渲染出的模型可见快照。一次 Turn 可以选中本地或远端多个环境；每个环境都必须把 cwd、Shell 和可用的仓库状态与实际执行后端绑定，不能拿宿主机信…

Permissions World State 把当前审批策略、沙箱策略和可写范围渲染成 Developer 上下文。它不负责执行授权判断；真正的工具调用仍由 Permission/Approval Runtime 校验。Prompt 里的权限说明与执行策略必须来自同一个 StepC…

模型切换涉及三个值：当前 ModelInfo、Session 持有的 Base Instructions、History 中模型可见的切换说明。ModelInstructionsState 只在模型身份真正变化且存在切换指令时发消息；PersonalityState 则判断人格是否已…

Collaboration Mode 和 Multi-Agent Mode 不是同一个开关。前者定义当前交互工作流及其 Developer Instructions；后者约束是否、何时以及怎样派生子 Agent。两者分别作为 World State section 持久化，避免模式更…

Codex 初始 Prompt 通常只注入可用 Skill 的目录元数据，不把所有 SKILL.md 全文塞进上下文。目录告诉模型“名称、用途、入口在哪里以及何时必须读取”；命中具体任务后，Agent 再通过文件或资源接口加载完整说明。这是典型的两阶段上下文设计。

Plugin 本身不是一种模型可调用工具，而是 Skills、MCP servers 和 Apps 的本地打包单位。Prompt 需要同时解释这种关系、暴露已安装能力，并在条件允许时把未安装推荐项作为 contextual user 信息注入。三类信息的角色与触发条件不同。

动态能力进入 Prompt 有两条主路径：可直接调用的工具变成 ToolSpec，沿 Prompt.tools 结构化通道发送；暂不展开的 Deferred Tool namespace 和 Extension 状态变成 World State 片段。把两者都写成自然语言工具清单，会…

ContextManager 是 Session 内原始 History 的唯一结构化所有者。它按最旧到最新保存 ResponseItem，同时持有 token usage、History version、TurnContext 引用项和 World State baseline。调…

ContextManager 对 History 只有少数受控变换：record_items 追加 API 可用项，remove_first_item 从最旧端删除并同步配对项，replace 整体重写并提升版本，rollback 按用户 Turn 边界裁剪。不同操作对 baseli…

普通函数调用靠 call_id 与 FunctionCallOutput 配对。发送前规范化执行两个方向的检查：有 call 无 output 时在 call 后插入合成 aborted；有 output 无 call 时删除孤儿 output。修复顺序固定为“先补缺，再删孤儿”。

Custom Tool、Local Shell 和 Tool Search 都有调用/结果关系，但结果类型与普通 Function 不完全相同。规范化器必须按调用种类选择正确的占位结果，不能用一个统一 FunctionCallOutput 覆盖所有协议变体。

Prompt-only 规范化不仅修调用配对，还根据目标模型的输入模态处理图片与音频。原则是保留事件存在的语义、移除模型无法消费的载荷：消息或工具结果里的媒体替换为明确文本，占位符告诉模型内容因能力不支持而省略。

Codex 的本地 Token 估算是字节启发式，不是模型 tokenizer 的精确复刻。它把 Base Instructions 与每个 ResponseItem 的“模型可见估算字节”相加，再按约四字节一 Token 换算；真实服务端 usage 到达后，则以 usage 为基…

Context Window Guidance、Token Budget Context 和 Token Budget Reminder 是三种不同信息：Guidance 告诉模型如何管理窗口；Context 标识当前窗口谱系；Reminder 在剩余 Token 低于阈值时一次性提…

Local Compact 不是在本地运行摘要模型，而是 Core 自己构造一轮带总结指令的普通模型采样，再由本地代码从输出中提取摘要、筛选保留用户消息并整体替换 History。它与 Remote Compact 的区别在“谁定义压缩协议和返回形状”。

Remote Compact 把类型化 History、Base Instructions、ToolSpec 和推理设置发送到专用 compact endpoint，由服务端返回替代 transcript。返回成功还不等于已经改变 Session；只有经过过滤、初始上下文处理并调用 …

压缩替换 History 后，旧 World State baseline 默认失效。是否立即安装新基线取决于压缩发生位置：Pre-turn/手动压缩不在替代历史中注入初始上下文，下一正常 Turn 完整重建；Mid-turn 为了继续同一 Turn，必须把 canonical 初始…

Codex 的 prompt_cache_key 默认不是 Prompt 内容哈希，而是 Responses metadata 中的 Session ID；Guardian 等特殊会话可以覆盖。Key 只划定缓存归属，能否命中仍取决于请求是否拥有稳定而相同的前缀。因此真正的缓存设计散…

previous_response_id 用于 Responses-over-WebSocket 的机会式增量请求：只有当前请求的非 input 属性与上一请求一致，并且当前 input 严格延续“上一请求 input + 上一响应新增 items”时，客户端才发送尾部 delta。…

Core 内部 Prompt 保留五组核心字段；ModelClient 再结合 ModelInfo、Provider、Turn 推理设置和 Responses metadata 编译成 ResponsesApiRequest。标准 Responses 与 Responses Lite…

Prompt 测试应分两层：Core snapshot 验证模型可见角色、标记和顺序；HTTP/WebSocket 请求捕获验证最终 wire fields。只测某段文字“包含”不足以发现角色错误、重复注入、配对破坏或 Lite 方言映射错误。

沿一次真实模型采样拆解 Codex 的请求映射、SSE 与 WebSocket、ResponseEvent、流式提交边界、连接预热、Previous Response、重试与 HTTP 回退。

模型名称不能决定一次请求怎样发送。Codex 把“模型会什么”和“服务端怎样连接”拆成两份目录数据，再在请求点按能力门控字段；否则换一个兼容服务地址就会意外改变工具、推理或传输语义。

模型目录既不能每次启动都依赖网络，也不能永远相信打包时的旧数据。ModelsManager 把内置目录、磁盘缓存、远端响应和用户覆盖组合为一个有 ETag 与 TTL 的可刷新视图。

连接可以跨 Turn 复用，粘性路由令牌却绝不能跨 Turn 复用。Codex 用 Session 级 ModelClient、Turn 级 ModelClientSession 和可转移 WebsocketSession 把这两个看似冲突的需求分开。

Responses Lite 不是把标准请求发往另一个 URL，而是把顶层指令和工具重新编码进 Input 前缀，并关闭若干能力。Codex 在请求编译处完成这种方言适配，上游 Prompt 不需要理解线协议差异。

一个 Responses 请求同时需要认证、会话关联、Turn 归属、兼容投影和粘性路由，但这些字段不能由多个调用点各自拼装。Codex 先建立一份规范化 metadata 快照，再投影到 HTTP Header 与 WebSocket client_metadata。

Prompt 已是结构化对象，但还不是可直接发送的 JSON。ModelClient 在每次请求尝试中重新编译模型、Input、工具、Reasoning、输出 Schema、缓存键和 Provider 特例，并在网络前清理不能跨 Provider 的内部元数据。

HTTP 200 和连接正常关闭都不能证明一次模型响应成功。SSE 适配器只有在解码到 response.completed 后才结束；在此之前的断流、空闲超时和 incomplete 都是失败。

一条 WebSocket 能承载多次 response.create，但 Codex 没有靠任意 request_id 在客户端并发复用。每个响应期间独占连接流，直到 Completed 才允许下一请求，因此相关性由串行所有权而非猜测事件归属保证。

启动预热不仅做 TCP/WebSocket 握手，还发送一份 generate=false 的完整 Responses 请求并等待 Completed。成功后的连接、请求基线和 Response ID 可以被首个真实 Turn 消费；失败则不阻断 Session。

连接复用并不自动允许增量请求。Codex 要同时证明所有非 Input 属性相同，并证明当前 Input 以“上次请求 Input + 上次完成输出项”为严格前缀，才发送剩余 delta。

response.created 出现 ID 并不代表它可作为下一请求的可靠父节点。Codex 只在 Completed 时把 response_id 与所有 Done Item 一起提交给 WebsocketSession；任何断流、重连或消费失败都会让引用链失效。

WebSocket 是性能路径，不是完成任务的前提。握手返回 426 会立即回退；普通可重试流错误耗尽预算后也会回退。回退标志属于 ModelClient Session，后续 Turn 都直接使用 HTTP SSE。

一次 Responses 流不是一串同级消息，而是响应级生命周期包住若干 Item 级生命周期。Created 说明响应存在，Item Added 建立活动项，Delta 只更新暂态展示，Item Done 交付完整事实，Completed 才关闭采样边界。

文字 Delta 用来降低首字延迟，完整 Assistant Message 才是可记录事实。Codex 还在两者之间放了流式文本解析器，避免把 citation 标记、Plan 模式控制块或尚未判定的前缀直接展示。

Reasoning 流有两条不同合同：可展示的 Summary 带 summary_index 和分节事件，原始 Reasoning Content 带 content_index。并发摘要 Feature 还会把逐 Delta 模式切换为按完整 Summary Part 交付。

当前 Codex 并不存在一个为所有 Function Call 拼接 JSON 参数的通用流式累加器。标准 FunctionCall 的 arguments 在 OutputItemDone 中完整交付；只有 Custom Tool Input Delta 会路由给该工具可选的 Diff Consumer。

Apply Patch 的流式预览不是对半截字符串做正则猜测。专用 StreamingPatchParser 增量识别已足够确定的 Hunk，转换成文件变化，并以 500ms 节流发送 PatchApplyUpdated；完成时再强制解析尾部和冲刷 pending 更新。

同样名为“工具调用”的 ResponseItem 可能由客户端执行、由服务端托管执行，或只是展示服务端已经完成的动作。ToolRouter 不是看到 *Call 就一律本地 dispatch，而是按 Item 类型与 execution 字段分流。

active_item 是 UI 生命周期的暂态指针，不是正在拼装的权威历史项。权威内容来自 OutputItemDone；它会在工具开始执行前立即写入 History 与 Rollout，即使 Turn 随后取消，调用事实也不会消失。

在当前客户端源码中，Safety Buffering 不是一个扣住 Text Delta 的本地缓冲器。真正的安全缓冲由服务端决定；Codex 解析 wire 上的 buffering metadata，补齐更快替代模型并向 UI 发通知，内容事件仍按原顺序通过。

限流快照和重试延迟是两条不同数据流：前者持续告诉 UI 额度窗口，后者只控制一次失败后的等待。Codex 优先采用错误携带的 delay，否则使用带抖动的指数退避。

网络断开、HTTP 429、服务端 failed event 和 Provider 特有认证错误起初形状完全不同。Codex 先在 codex-api 保留传输细节，再由 Provider 映射成统一 CodexErr；上层只依据语义类别决定重试、回退、提示或终止。

服务端返回 ContextWindowExceeded 时，Codex 不在同一失败请求上盲目重试，也不会立即把半成品历史就地压缩后续跑。它先把 token 状态标记为已满并结束当前 Turn；下一次采样前的压缩检查才使用完整压缩流程。

Codex 把 final_output_json_schema 编译成 Responses text.format，严格模式由服务端约束模型输出。通用采样链不会再在本地用 JSON Schema 验证一次；它仍把最终内容作为 Assistant Message 文本交付，专用调用方可再反序列化自己的领域类型。

Turn 取消不是把网络 Task 粗暴遗忘。采样等待点把 CancellationToken 映射为 TurnAborted，随后 flush 解析器、取消并 drain 已启动工具、丢弃 ResponseStream 以通知映射任务；只有已经收到 Item Done 的事实留在 History。

Realtime 和 Responses 都能看到 WebSocket 与 response.create，但不能共用同一状态机。Responses 服务一次离散采样和工具循环；Realtime 管理长连接音频、转录、VAD 打断、会话更新与 Codex handoff，是独立的对话子系统。

从完整 Tool Call 追踪 Codex 的工具双面合同、Step 级路由、Hooks、并行执行、Unified Exec、Apply Patch、命令策略、审批和平台沙箱。

从 Codex 的实现中提炼 Function Tool 设计：模型合同与执行表为什么来自同一 Step，外部 Schema 怎样编译，Lite 请求怎样承载工具，以及返回参数为什么仍要由 Handler 校验。

多个 Executor 可以各自贡献同名 Namespace，但模型请求只能拿到一个稳定分组；当前实现先合并，再按 Provider 的 Namespace 能力决定是否保留。

Freeform Tool 允许模型输出一段受 Grammar 约束的文本，而不是 JSON 对象；Grammar 属于模型合同，完整文本仍必须由客户端 Parser 重新验证。

Tool Search 的 execution 标记决定调用由客户端还是 Hosted 服务执行；只有带 call_id 且 execution=client 的完成项才进入本地 Handler。

Hosted Web Search 没有本地 Handler。Codex 只把 mode、过滤器、位置、上下文大小与内容类型编译成服务端规格。

工具路由身份是 Namespace 与 Name 的二元组，不是随意拼接的显示字符串；扁平兼容名只用于特定协议和 Hook。

Exposure 同时控制初始可见性、Tool Search 与 Code Mode 接入方式；四个状态不能简化成 visible=true/false。

一次 Step 的工具来自 Shell、MCP 资源、核心工具、多 Agent、扩展、动态工具和 Hosted Specs；规划函数用固定次序收集并施加模式改写。

工具存在于代码库不等于当前会话能用。规划器同时读取 Feature、Provider capability、模型模态、环境数量、账户方案和客户端类型。

模型可见规格和执行表必须来自同一批 PlannedRuntime，并与原 StepContext 一起存活到工具调用完成。

完整 ResponseItem 到达后，Router 才按变体建立 ToolName、ToolPayload 与 call_id；参数 Delta 不会提前启动工具。

ToolPayload 是本地路由的判别联合：同名 Handler 也必须明确接受哪种载荷，类型错配属于 Runtime 契约错误。

通用 ToolExecutor 把规格和执行绑定；CoreToolRuntime 再增加 Payload 匹配、Hook、遥测、取消和 Diff Consumer 等 Codex 语义。

Pre Hook 在副作用前可以阻断或改写输入；Post Hook 在执行后只能改变反馈，不能撤销已经发生的副作用。

工具执行同时服务模型、界面和可观测性：Start/Finish、TurnItem、Telemetry 与 Trace 必须共享 call_id，却不能互相冒充。

支持并行的工具可同时运行，但串行工具形成写锁屏障；无论完成顺序如何，FuturesOrdered 按模型调用顺序回灌结果。

不同 Runtime 可以返回不同内部结果，但进入 History 前必须编码成与原调用种类匹配的 ResponseInputItem。

模型上下文截断、终端 Head/Tail 缓冲和 Telemetry 预览是三套不同预算；不能用日志看见的文本推断模型收到的完整内容。

Turn 取消不能让已记录的 Tool Call 永久没有结果。Runtime 要么中止 Future，要么等待资源自清理，最后编码 Aborted Output。

shell_command 接受字符串或字符串数组；数组表示多条命令按工具协议批量执行，不应被误读成单条 argv。

同一条模型命令要经过目标 Shell 适配：Unix 登录 Shell、非登录 Shell和 Windows 调用方式不能共用一套 argv 拼接。

Handler 不直接 spawn。它先选环境、应用 Turn sticky permissions、识别 Patch、求值 Exec Policy，再通过 Orchestrator 执行。

Shell Runtime 先在有效 Permission Profile 下选择 Sandbox Attempt；只有判定为 Sandbox Denied 且工具/审批策略允许，才进行一次更高权限尝试。

Zsh Fork Backend 复用预热 Shell 状态再 fork 子命令，以降低反复启动成本；它是本地优化，不改变 Tool Call 审批和输出合同。

exec_command 把“启动命令”和“短暂等待结果”合成一次调用；命令未结束时返回 session/process ID，后续由 write_stdin 继续交互。

ProcessManager 在启动前预留 ID，并在首次返回后台状态前把 Live Process 原子放入 Store，避免 write_stdin 查到半初始化对象。

Unified Exec 为 stdout/stderr 建立异步读取任务，并把聚合输出写入有界 HeadTailBuffer；慢消费者不能让内存无限增长。

exec_command 在首次等待窗口内竞争“进程退出”和“yield 到期”；后台化必须先完成 Store 注册，再向模型公布可交互 ID。

write_stdin 同时承担 TTY 输入和后台轮询：非空 chars 写入 stdin，空 chars 只等待新输出；两者使用不同 yield 上限。

Unified Exec 的 expiration、Turn cancellation、显式 terminate 和 Store pruning 是不同回收触发器，最终都要让 watcher、reader 与审批状态一致结束。

用户在界面直接运行 Shell 是 Op::RunUserShellCommand，不是模型提出的 Tool Call；它使用 ExecutionSource::UserShell 并以 contextual item 记入会话。

Apply Patch 使用 Freeform + Lark Grammar，让模型直接生成补丁文档；多环境时才把 environment_id 作为格式扩展加入合同。

补丁文档把文件操作分成 Add、Delete、Update；Move 是 Update 的可选目标，不是独立无内容复制命令。

Patch Parser 用上下文序列在原文件中定位 Hunk，并按 exact、rstrip、trim、Unicode 标点正规化逐级放宽匹配。

Parser 接受相对和绝对路径，本身没有“只能工作区内”的硬拒绝；真正边界来自路径解析后的权限、审批与平台沙箱。

Handler 先解析、选环境、验证 Patch Action 并计算涉及路径，再按当前权限请求附加写范围；最终可走 Orchestrator 或兼容直接执行路径。

Shell/exec_command 参数若被识别为 apply_patch 调用，会验证命令形状并转入专用 Patch Handler，而不是启动 Shell 脚本写文件。

当前补丁应用是顺序文件操作，不是跨文件事务。后续写入失败时，之前成功的写入可以保留，并通过 committed delta 返回。

TurnDiffTracker 持有一次 Turn 的文件快照与累计 Delta，工具完成后生成统一 Diff 事件；它是观察层，不是写入事务。

Apply Patch 参数 Delta 可以驱动实时预览，但预览 Parser 与约 500ms 合并窗口只服务 UI；最终执行仍等待完整 ResponseItem Done。

view_image 先按原 Step 选择环境并解析路径，再通过受限文件系统读取字节；Handler 构造 data URL，但真正的图片解码/缩放由历史内容处理层完成。

view_image 的 detail 字段只有模型支持原图能力时才进入 Schema；否则请求会按 high/default 处理，不能靠参数绕过模型能力。

update_plan 的说明要求最多一个 in_progress，但当前 Handler 主要做类型反序列化、模式门控和 PlanUpdate Event；它没有再次遍历计划强制该数量约束。

request_user_input 只在根 Thread 和允许模式工作。Handler 注册 call_id 对应 oneshot，发出请求事件，然后等待用户响应、自动决议或取消。

request_permissions 把模型提出的附加文件/网络权限编译成 RequestPermissionProfile，经 Hook/Guardian/用户响应后更新 Turn 或 Session 的 sticky grants；它不改写基础配置文件。

wait_for_environment 观察 Step 中处于 starting 的环境并等待 ready；工具参数没有独立 timeout 字段，超时/失败属于环境启动生命周期。

current_time 通过 Session TimeProvider 获取当前时间，并可把结构化提醒注入上下文；它不直接调用操作系统全局时钟。

clock.sleep 只接受 1 秒到 12 小时，并在新用户输入/队列活动出现时提前结束；它不是不可中断的 blocking sleep。

new_context 工具只在 Session 标记“请求新上下文窗口”；它不会在 Handler 内立即压缩或改写当前 History，也不会生成摘要。

get_context_remaining 从 Turn/Session 的 context_window_token_status 读取预算，并返回可选 base_window_tokens_remaining；它报告 Runtime 估算，不向 Provider申请新 Token。

Deferred Runtime 不进入初始模型工具列表，而是从规格提取名称、说明、属性名和来源，生成可索引 SearchInfo。

本地 tool_search 用英语 BM25 索引 SearchInfo 文本，query 必须非空，limit 必须大于零；命中结果按来源/Namespace 重新合并。

Tool Search 命中不会就地修改正在进行的模型请求；结果先编码成 completed/client ToolSearchOutput 写入 History，下一次采样再由模型读取返回规格。

ToolMode=CodeMode/CodeModeOnly 时，规划器前插公开 exec 与 wait，并把可嵌套 Runtime 收进 JavaScript Tool 环境；CodeModeOnly 还从顶层隐藏普通 Direct 工具。

Code Mode exec 接收带可选 pragma 的 JavaScript，自 V8 Cell 启动后等待首次 Terminal 或 Yielded；Yielded 时 Cell 继续运行并由 wait 后续观察。

JavaScript 中的嵌套工具名由 Namespace/Name 规范化：通常使用 namespace__name，边界下划线规则避免多加分隔符；Broker 再映射回完整 ToolName。

wait 工具按 cell_id 继续观察已 Yielded Cell，可设置 yield/max_tokens 或 terminate；它是 Cell 控制面，不再运行普通 Pre/Post Hook。

配置可以把特定 Namespace 排除出 Code Mode；这些工具保留普通顶层合同。direct_only_tool_namespaces 则把 Direct/Deferred 改成 DirectModelOnly。

Dynamic Tool 由当前 Thread 提供 Function/Namespace Spec，Core 转成 Responses 规格并注册等待响应的 Handler；调用通过 oneshot 回到宿主。

扩展的 ToolContributor 先解析为通用 ToolExecutor，Core 用 ExtensionToolAdapter 注入 History、Turn Metadata、环境文件系统上下文和事件发射器。

当 standalone web.run 扩展已启用且实际贡献执行器时，它优先于 Hosted Web Search；否则 Provider 支持时才建立 Hosted 规格。

Image Generation 是扩展工具，但 Core 在注册前执行严格可用性判定：Feature、账户、Provider、Namespace、模型 Image 模态和认证路径缺一不可。

MCP Binding 把 Server 工具转成 Namespace ToolSpec 和规范 ToolName；旧 mcp__ 前缀只保留给 Hook/兼容显示，不能取代 canonical identity。

MCP 调用先解析 JSON、刷新 dirty Binding、重新 prepare_call，再应用 App Tool Policy、Hook/Guardian/用户审批和参数重写，最后才发往 Server。

MCP CallToolResult 可以含文本、图片、音频、ResourceLink 与 EmbeddedResource；Core 保留内容项类型并把 isError 映射为工具成功语义。

McpToolOutput 在进入模型前附加 wall time、清理图片 detail 并按模型策略截断；Pre/Post Hook 使用带 mcp__ 前缀的兼容工具名和结构化输入/输出。

资源列表可指定 Server 和 opaque cursor；未指定 Server 时聚合所有模型可访问 Server，但此时禁止 cursor，因为不同 Server 的分页游标不可合并。

Resource Template 描述带参数的 URI 模式；列表工具复用资源分页框架，但调用 resources/templates/list 并返回模板元数据。

read_mcp_resource 强制要求非空 server 和 uri，先验证模型可访问 Server，再把精确 URI 交给该 Server 的 resources/read。

插件候选来自配置、远端 PluginsManager、禁用列表、已加载 Connector 和客户端过滤；列表 Handler 只返回预先计算的候选快照。

request_plugin_install 先校验候选 ID、类型、来源展示模式和非空理由，再通过 codex-apps MCP elicitation 请求用户确认；确认后还要验证安装完成并刷新选择。

权限配置可以选择内建 read-only/workspace/danger-full-access 或继承的命名 Profile；解析器先解析身份与约束，再把具体文件/网络策略和 workspace roots 原子装入 TurnContext。

Approval Policy 决定何时可以询问，不直接定义文件/网络权限。Never 不弹窗但危险命令可 Forbidden；OnRequest 通常先在受限沙箱运行，只有明确需求或拒绝后才申请升级。

ExecPolicyManager 把 Shell wrapper 尽量降成命令片段，用显式 prefix/network rules 与 unmatched heuristics 求 Allow/Prompt/Forbidden；保存前缀前再次验证它能覆盖全部片段且不过宽。

Guardian 在 OnRequest/Granular + AutoReview 时替代用户自动审查具体动作。它用受限 transcript、精确 action JSON 和严格输出 Schema运行独立 Review Session，并对超时/解析失败 fail closed。

SandboxManager 根据有效文件策略、网络策略、工具 preference、managed network 需求和平台能力选择 None、MacosSeatbelt、LinuxSeccomp 或 WindowsRestrictedToken，再把原生命令转换成平台启动请求。

macOS 用固定 /usr/bin/sandbox-exec 和动态 SBPL：基础策略 deny default，再按可读/可写根、拒读 glob、元数据保护和网络代理端点拼接 allow/deny 规则。

当前 Linux 主路径由 bubblewrap 负责文件系统挂载/遮罩与 user/pid/network namespace，进程内 no_new_privs + seccomp 负责网络 syscall 限制；legacy 模式才直接安装 Landlock 文件规则。

Windows Restricted Token 路径把能力 SID、Workspace ACL、拒读/拒写路径、网络隔离和 Job Object 组合起来；CreateRestrictedToken 只是一层，不是完整沙箱。

Managed Network Proxy 在连接发生时按 host/protocol/port 评估 allow/deny/ask；allowlist miss 只有 Approval Policy 和 Managed Permission Profile 允许时才进入按域审批。

Sandbox Denied 是首轮执行结果的分类，不是任何非零退出。Orchestrator 同时检查工具可升级、策略可提示、denied-read、网络拒绝原因和先前审批范围，最多重试一次。

第六章最终边界不是“开了沙箱就安全”，而是四层组合：Hook 扩展组织规则，Exec/Network Policy 分类动作，Approval 决定一次例外，Permission Profile+Sandbox 强制资源边界。

沿 Codex 源码追踪子 Agent 的 Thread 身份、Spawn/Fork、上下文继承、mailbox 通信、完成回传、执行与驻留容量，以及持久父子拓扑。

Codex 没有一个包办全部语义的 Agent 对象：AgentPath/ThreadId 负责寻址，Role 负责派生配置，Session 持有运行状态，Prompt 与工具面按 Turn/Step 编译，AgentStatus 只是事件投影。

Role 是高优先级配置层而不是整份配置替换：内建 default/awaiter/explorer 与用户 Agent TOML 走同一解析语义，Role 只覆盖自己声明的字段。

AgentRegistry 用一次可回滚预留同时保护总量、路径和昵称；只有子 Thread 创建成功后才 commit 元数据，失败路径由 Reservation 的析构回滚。

AgentStatus 是从 Session 事件流提炼的粗粒度快照；Interrupted 明确不是 final，因此既可再次接收任务，也不能被完成等待逻辑误判为已经结束。

Codex 的“最多多少 Agent”不是一个计数器：V1 深度/总量、V2 执行 Guard、Residency 已加载上限和持久拓扑分别约束不同资源。

Residency 把“Agent 仍存在”与“Session 当前驻留内存”分开：安全卸载只移除运行时对象，后续通信按原 ThreadId 从 StoredThread/History 重建。

Spawn 的关键不是调用 ThreadManager 一次，而是按顺序冻结版本、能力、路径、角色、环境与历史，并在每个可能失败的阶段保持 Reservation/Residency 可回滚。

V2 Fork 复制的是可安全复用的对话语义，不是父 Rollout 的字节副本：Reasoning、工具轨迹、旧通信和非最终 Assistant 消息被过滤，TurnContext/WorldState 仅在可作为 reference context 时保留。

Fork 不能让子 Agent 同时服从父身份和子 Role；Codex 在顶层历史、Compact replacement history 与缺失 reference context 三处统一替换/补入子 Developer Instructions。

V1 以 ThreadId/UUID 为后续工具地址，支持显式 message/items、agent_type、模型覆盖与布尔 fork_context，并受派生深度限制；它与 V2 的 task_name/AgentPath 协议不是同一层包装。

V1 `send_input` 不是简单 Mailbox：可选 interrupt 会先取消目标活动 Turn，随后以 UserInput 携带父 TurnId 投递；目标是否新建 Turn由 Session 当前活动状态决定。

V1 resume 先检查内存 Thread；NotFound 时才用目标 ThreadId 读取 Rollout 并恢复 Session，还会沿 AgentGraphStore 的 Open 子边递归恢复后代。

V1 wait 是目标状态 watcher 的 fan-in：先返回已经 final 的目标，否则并发订阅多个 Agent，直到至少一个进入 final 或超时；输入超时会被夹在配置范围内。

V1 close 是拓扑和运行时的联合关闭：先把非临时父子边标为 Closed，再对目标及当前可见后代执行物化、Shutdown、等待和 Registry/Residency/Manager 清理。

V2 用 task_name 构造规范 AgentPath，以 fork_turns 精确选择历史窗口，并让模型/reasoning 覆盖、Step 环境与结果元数据在同一请求中冻结。

V2 send_message 只把 InterAgentCommunication 追加到目标 Session 的 Mailbox，并通知 Activity watcher；它不创建新 Turn，空闲目标会把消息留到下一次自然启动。

followup_task 与 send_message 复用地址/恢复/投递骨架，差别集中在 trigger_turn=true：空闲目标会以通信内容启动新 Turn，活动目标则把任务并入后续输入。

V2 wait 没有 targets 参数，也不观察子 Agent 状态；它订阅当前 Session 的 InputQueue Activity，在已有 pending steer/mail 时立即返回，否则等待 Mailbox、Steer 或 deadline。

V2 interrupt 只取消目标当前 Turn，不关闭 Agent；工具先记录 previous_status，拒绝 root/self，再提交 Interrupt，并把目标已消失/已死亡视为幂等成功。

list_agents 先把可选 path_prefix 相对当前 Agent 解析，再从 Registry 地址集合投影状态；当前实现只返回此刻仍能从 ThreadManager 取到的已加载 Thread，因此它不是持久拓扑全集。

V2 子 Agent 完成或出错时，Session 把格式化结果作为 trigger_turn=false 的通信投递给直接父节点；成功投递会唤醒 wait_agent 的 Activity watcher，却不会自行启动父 Turn。

AgentGraphStore 只持久化 ThreadSpawn 父子拓扑：每个 child 有唯一入边，Open/Closed 表示关系是否可恢复，查询后代按 BFS 且状态过滤作用于每条被遍历边。

V2 不是 V1 的改名版：二者在地址、Fork、消息、等待、完成通知、容量和恢复上都有不同可观察合同；混用任一项都会制造错误调用链。

Skill Loader 从项目、用户、系统、管理员、插件和额外根目录收集候选，以根顺序表达优先级；扫描并发执行但合并时恢复确定顺序，并用深度/目录/条目上限约束不可信目录树。

Codex 先用有限预算把 enabled 且允许隐式触发的 Skill 名称/描述/locator 列给模型；明确命中后才读取完整 SKILL.md，并以 ContextualUser SkillInstructions 注入当前 Turn。

scripts/assets 是由 Skill 指令按需引用的资源，不自动进入 Prompt；结构化 dependencies 中的 MCP 项则在注入前检查缺失、按策略征求许可、写入全局配置、完成 OAuth 并刷新运行时。

McpConnectionSet 为一代 Server 配置管理启动任务、Ready/Pending/Failed 视图、工具缓存、认证和 elicitation；新一代配置只复用连接身份与授权语义都兼容的旧 client，未复用者由生命周期收尾关闭。

当前实现不依赖一个泛化的 tools/list_changed 推送链：普通 dirty refresh 为后续 Step 发布新 ConnectionSet；同一 ConnectionSet 内的 Codex Apps hard refresh 才递增 Catalog Revision，并让旧 PreparedCall 在副作用前失败。

MCP Resource 是由精确 Server client 分页列举/读取的数据能力，Elicitation 是 Server 向宿主发起并等待精确 response token 的反向请求；锁定版本没有把 MCP Prompts 暴露为 Codex 客户端工具。

Plugin 用 Manifest 声明 skills/MCP/apps/hooks/interface，Bundle 给声明提供受控根目录，Marketplace 只负责列出可安装来源和策略；所有相对路径都必须解析在 Plugin root 内。

插件变更是“解析策略→物化到 staging/store→激活版本→写用户启用状态→刷新缓存/能力”的多阶段事务；Marketplace 启动同步优先 Git，再退到 GitHub HTTP，只有本地快照缺失时才用滞后的 export archive。

App declarations 只有在 AuthMode 使用 Codex backend 时保留；插件 active 且声明 App 时，同名普通 MCP server 被剔除，避免一项 App 能力同时通过 backend route 和本地 MCP route 暴露。

Hook Engine 从受管要求、分层 config.toml/hooks.json 与插件清单发现 handlers，先应用 managed-only/trust/state 策略，再按事件 matcher 选中；命令以 JSON stdin、受限环境、cwd、timeout 和 kill-on-drop 并发执行。

Hook 不是一个通用 JSON blob：每个事件有独立输入 schema，公共字段只负责 session/turn/cwd/transcript，Tool 事件增加 tool_name/input/response，Compact 增加 trigger，Subagent 增加 agent 身份。

Hook stdout 必须解析成事件专属 wire schema；合法 Additional Context 被转成独立 Developer messages 记录进历史，PreToolUse 只有 Allow 才接受 updated_input，Block 必须携非空 reason，坏输出不能被当作授权。

进程内 Extension 通过 Builder 按 contributor 类型注册成不可变 Registry；私有状态不塞进 Core 结构，而是按 Session/Thread/Turn/Step 创建 ExtensionData，以 TypeId→Arc 的类型映射隔离生命周期。

ContextContributor 同一接口覆盖稳定 Thread Context、Turn Context 和 WorldState，但产物有不同安装协议：PromptFragment 按 slot 进入 Developer/ContextualUser，WorldStateSection 用稳定 id+snapshot+diff renderer 支持跨 Step 增量。

Extension API 把“拥有能力”和“观察/改写结果”拆开：ToolContributor 产出 Step 绑定的原生执行器，McpServerContributor 叠加 server 配置，TurnInputContributor 加模型输入，TurnItemContributor 只在解析后按顺序后处理 Item。

Lifecycle Contributor 运行在 Host 明确拥有的闸门：Thread start/resume/idle/stop 与 Turn start/stop/abort/error；回调只拿稳定 id、配置快照和 scoped stores，不暴露 Session 内部锁。

Hooks 是配置/插件提供的外部命令：要经过 discovery trust、matcher、timeout、JSON schema 和输出限制；Extension 是编译进宿主进程的 Rust 代码：拥有 typed capabilities、可直接贡献工具/上下文，因此信任更高且故障半径更大。

沿 Codex 源码拆解 Context History、Rollout、ThreadStore、SQLite 投影与 AgentGraphStore 的权威边界，并追踪写入屏障、重放式恢复、工具调用尾部修复、Compact、Fork 和 Legacy Rollback。

从 Context History、Rollout、ThreadStore、SQLite 与 AgentGraphStore 的问题域出发，建立 Codex 恢复系统的状态权威边界。

逐项分析 RolloutItem、ResponseItem 与 EventMsg 的白名单，以及 Legacy/Paginated 如何选出唯一的可重放表示。

还原 Session 先尝试持久化、再投递客户端的真实顺序，并分析两侧有顺序但不原子时的故障组合。

从有界命令队列、Writer State 与 oneshot 确认出发，区分 AddItems 入队、Persist、Flush、Shutdown 和重试的保证。

新 Thread 可以先存在于内存而没有 Rollout 文件，但一旦物化，第一条规范记录必须是预先构造好的 SessionMeta，后续读取以它确定身份和 History Mode。

一次批量写入可能只成功前几行；Recorder 只删除已经确认写出的 pending 前缀，并在重开文件后继续未写后缀，避免整批重试造成重复。

四个看似都在“保存”的操作具有不同线性化点：Persist 保证存在，Flush 确认既有队列，Shutdown 排空并结束所有权，Discard 则丢弃 Live Writer 而不强迫 pending 落盘。

JSONL 的恢复策略把“行边界安全”和“每行内容有效”分开：追加前补齐缺失换行，读取时跳过空行与坏行并计数，但绝不把坏行解释成完整记录。

Paginated 历史用逻辑 ordinal 与物理 byte offset 的组合定位前缀：前者约束顺序，后者冻结具体文件边界，二者共同支撑分页、Fork 和增量投影。

冷 Rollout 压缩是后台 best-effort 表示变换，不改变逻辑历史；任何需要追加或引用物理前缀的路径都会先把 `.jsonl.zst` 安全物化回普通 JSONL。

反向读取不是把整份日志载入内存后 reverse；ReverseJsonlScanner 从给定 byte offset 以 8 KiB 块向前读，跨块拼接一行，并让坏记录不会终止继续扫描。

引用式 Fork 使 Rollout 文件不再彼此独立；RolloutReferenceIndex 扫描 active 与 archived 元数据，建立 source→referrer 的直接引用计数，供压缩和删除执行保留判断。

Core 依赖的是 Thread 生命周期和历史能力，而不是 JSONL 目录布局；ThreadStore trait 把 Live 写入、冷读取、Fork 准备、查询和归档删除收束成存储中立契约。

LiveThread 是 Session 对持久化生命周期的句柄；初始化只有在 Session 全部建立后才 commit，任何中途失败都由 InitGuard discard 已注册 writer，避免留下半初始化所有权。

进程内 mutex 只能约束一个 LocalThreadStore；Paginated Thread 还用每 Thread 文件锁阻止另一个 Codex 进程同时追加同一 ordinal/offset 序列。

Paginated 写入采用单向一致性：规范 JSONL 必须先成功，SQLite Projection 才能 best-effort 追赶；数据库允许落后，绝不允许先行宣称一条尚未耐久的历史。

Thread 列表元数据不是每次重扫全日志得到的快照；MetadataSync 从已持久化项增量观察 preview、cwd、模型、Token、Goal 和 Git，并用 generation 防止慢更新覆盖新事实。

Paginated Projection 不是把每条 JSONL 原样复制进 SQLite，而是把 TurnStarted/终态和 ItemCompleted 归约成可分页的 Turn/Item 行，并以物理位置记录增量进度。

引用式 Fork 的逻辑历史横跨多个物理文件；分页、按 Turn 查找和全文搜索都必须先解析 lineage，再在可见 segment 范围内处理 cursor 与同 Turn shadowing。

Resume 保留 Thread 的 durable identity，却重新创建任务、channel、服务连接、锁和 Session 状态；旧进程内对象从不被序列化复活。

恢复算法先从尾部反向寻找最小充分基座，再把保留下来的后缀按原顺序前向重放；反向阶段决定“从哪里开始”，前向阶段决定“最终是什么”。

恢复不只得到消息数组；它还要找出最近一个存活且完成的用户 Turn 设置，并恢复 compaction window number/ID 链，才能让下一 Turn 正确比较配置和延续请求缓存作用域。

WorldState 持久化的是可重放快照链：新窗口或无基线时写 full，稳态只写 JSON Merge Patch；恢复必须按时间顺序应用，并在 Compact 或非法 Patch 处重置可信基线。

崩溃可能留下只有 Call 或只有 Output 的尾部；Codex 在生成模型 Prompt 的副本上补 aborted Output、删除孤儿 Output并剥离不支持媒体，但不把这些推断反写成真实 Rollout。

Compaction 的耐久结果不是一条“已经总结”的提示，而是一份可直接接管 Context History 的 replacement_history，加上窗口身份、WorldState full 和可选 TurnContext 基线。

Local Compact 与 Remote Compact 产生摘要的路径不同，但最终都必须收敛到同一个 replacement checkpoint；差异集中在输入裁剪、输出过滤、重试和上下文注入位置。

Legacy Rollback 不删除旧行，而是在 flush 后对“旧历史 + 新 marker”做一次完整重建，先更新热 Session，再把同一 marker 追加并刷新；分页模式在 App Server 入口明确拒绝。

Copied Fork 不是原样复制父 Rollout：它先构造对 child 合适的模型历史，过滤 Reasoning/工具/旧通信和非最终 assistant，再由 child Create 路径写自己的 SessionMeta。

Reference-backed Fork 不复制祖先字节，而是把 ThroughTurn/BeforeTurn/Latest 解析成 HistoryPosition，并在 child SessionMeta.history_base 中冻结该物理前缀。

一个 Paginated child 的逻辑历史是有序的物理 segment 列表；Lineage resolver 沿 history_base 追溯、验证每个 cutoff 并反转顺序，所有 Reader 只能消费这些有界段。

Archive 是在 active/archived 集合之间移动 Rollout 并更新元数据；Delete 是不可恢复移除，必须先锁住生命周期、预检引用，并在批量场景区分内部引用与外部引用。

“State DB”不是一张万能表：StateRuntime 管理五个 SQLite 文件，把 Thread 元数据、Log、Goal、Memory 和可重建 Paginated History 隔离，以降低写锁竞争并明确恢复等级。

AgentGraphStore 恢复“谁由谁 spawn、边是否 Open”，ThreadStore 恢复“每个 Thread 说过和做过什么”；V1 后代恢复先用图找身份，再逐个用 Rollout 创建新 Session。

Codex 的崩溃一致性不是“成功或什么都没发生”；模型流、工具副作用、Context History、Rollout pending、JSONL 和 SQLite Projection 各有独立提交点，恢复必须按留下的证据分层处理。

从 Op/Event、Turn/Step、真实 Responses/SSE、工具与安全，一直实现到 Writer、Resume、MCP、Agent Mailbox 与故障测试。

从锁定 Codex 源码与可运行 Mini Codex 拆解Python 领域协议：Op、Event 与 ResponseItem的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解有界 Queue、反压和关闭哨兵的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Session 主循环与活动 Turn 所有权的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解TurnContext、StepContext 和 WorldState 刷新的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解PromptCompiler 与 HistoryManager的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解ModelClient Protocol 与真实 Responses Adapter的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解SSE 事件解析和 ResponseAccumulator的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解ToolRegistry、ToolPlan 与同 Step Router的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Shell Tool 的进程、超时、取消和输出截断的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Unified Exec 的持续进程和 stdin 续写的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Apply Patch Grammar、Parser 与安全写入的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Approval、Exec Policy 与可替换 Sandbox Adapter的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Tool Hook、生命周期事件和失败结果回灌的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解JSONL Writer Task、Flush 和故障注入的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Resume、Call/Result 修复与不完整 Turn的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解Compact、Rollback 和 Fork的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解MCP Adapter 与动态工具目录的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解子 Agent、Mailbox 和容量控制的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解端到端真实模型测试与录制回放测试的状态、顺序、故障与设计边界。

从锁定 Codex 源码与可运行 Mini Codex 拆解故障矩阵、类型检查、并发测试和性能基线的状态、顺序、故障与设计边界。

从状态所有权、双快照、Prompt、工具、安全、持久化、多 Agent 与扩展边界，提炼可迁移的 Agent Runtime 合同，并划清不应机械照搬的产品复杂度。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“Event-driven Runtime 的必要复杂度”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“Turn 稳定快照与 Step 动态快照”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“Prompt 编译和缓存友好设计”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“Tool Spec 与 Runtime 的同快照契约”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“工具生命周期与副作用控制”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“应用策略、人工审批和 OS 沙箱分层”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“多层持久化权威的收益与成本”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“多 Agent 的收益、容量和恢复成本”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“Hooks、MCP、Plugins 与 Extension 的边界”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“Mini Codex 故障测试证明了什么”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“可迁移到其他 Agent Runtime 的设计”的适用条件、失败边界和迁移成本。

从锁定 Codex 源码、前九章证据与 Mini Codex 故障测试，分析“不应机械照搬的 Codex 产品复杂度”的适用条件、失败边界和迁移成本。

《读懂 Codex：从大模型到智能编程助手》R4 PDF，提供 1552 页完整参考版、99 页主干学习版和文件校验信息。