Cargo 工作空间全景

Codex 的 Rust 工作空间不能用“codex-rs/ 下有多少目录”来计数。容器目录 ext/、memories/、utils/ 下还有嵌套 package，tests/common 也可以是 package；反过来，.cargo/、docs/ 和 vendor/ 又不是 package。

对 Cargo 而言，准确答案来自 workspace manifest 和 cargo metadata。在这个版本中：

packages、workspace_members 和 workspace_default_members 都是 142；
142 个 package 全部继承 workspace 版本 0.150.0、Rust 2024 edition 和 Apache-2.0 license；
31 个 package 至少有一个 binary target，2 个是 proc-macro package，6 个有 build script；
只有 codex-backend-client 显式设置 publish = []（禁止发布）。

本文的完整矩阵为每个 package 给出 manifest 路径、target 形态、直接职责和源码专题归类。专题归类只用于导航，不代表 Cargo 依赖层级；真实依赖方向由 Crate依赖边界单独建模。

本文是一份 Cargo/package 参考表，用于回答“某个 crate 在哪里、产生什么 target、归哪个专题”。一旦问题进入函数调用、状态所有权或依赖边的运行含义，就应停止查矩阵，转入文末链接的专题正文；package 数量本身不能解释运行时架构。

1. Cargo metadata

本文使用 --no-deps，因为问题是“仓库自己定义了哪些 package”，而不是盘点 crates.io 依赖。该选项会保留 workspace package 的 manifest、target、feature 和发布属性，同时不生成完整依赖 resolve 图。

bash

cargo metadata \
  --manifest-path codex-rs/Cargo.toml \
  --no-deps \
  --format-version 1 \
  > /tmp/codex-metadata.json

jq '{
  packages: (.packages | length),
  workspace_members: (.workspace_members | length),
  default_members: (.workspace_default_members | length)
}' /tmp/codex-metadata.json

输出的三个数字都是 142。后续矩阵直接使用 .packages[] 的 name、manifest_path 和 targets[].kind，避免对目录或二进制名做隐式推断。

Cargo.lock 在 --no-deps 清单中不会把外部依赖变成 workspace package；它的作用是锁定实际解析的依赖版本。图中把 manifest 和 lockfile 分开，正是为了区分“我们定义的 package” 与“这些 package 解析到的依赖”。

根 manifest 的成员表直接体现了仓库如何把产品、协议、基础设施和扩展放进同一个解析单元。下面保留一段连续源码，以免分类结论只来自生成后的矩阵：

源码位置：codex-rs/Cargo.toml :: [workspace].members（节选）

toml

[workspace]
members = [
    # 前几项既有共享服务，也有 App Server 产品边界。
    "aws-auth",
    "analytics",
    "agent-graph-store",
    "agent-identity",
    "backend-client",
    "bwrap",
    "ansi-escape",
    "async-utils",
    "app-server",
    "app-server-transport",
    "app-server-daemon",
    "app-server-client",
    "app-server-protocol",
    "app-server-protocol-noop-macros",
    "app-server-test-client",
    "apply-patch",
    "arg0",
    "feedback",
    "features",
    "install-context",
    "codex-backend-openapi-models",
    # Code Mode 被拆成协议、runtime、host 与产品入口多个 package。
    "code-mode",
    "code-mode-host",
    "code-mode-protocol",
    "code-mode-runtime",
    "codex-home",
    "cloud-config",
    "cloud-tasks",
    "cloud-tasks-client",
    "cloud-tasks-mock-client",
    "cli",
    "collaboration-mode-templates",
    "connectors",
    "config",
    "context-fragments",
    "shell-command",
    "shell-escalation",
    "skills",
    # core 与 core-api 同属 workspace，但后者只是面向宿主的 facade。
    "core",
    "core-api",
    "core-plugins",
    "core-skills",
    "hooks",
    "http-client",
    "secrets",
    "exec",
    "file-system",
    "exec-server-protocol",
    "exec-server",
    "exec-server/tests/support",
    "execpolicy",
    "ext/agent",
    "ext/connectors",
    "ext/extension-api",
    "ext/goal",
    "ext/git-attribution",
    "ext/guardian",
    "ext/image-generation",
    "ext/items",
    "ext/memories",
    "ext/mcp",
    "ext/skills",
    "ext/web-search",
    # ...
]
resolver = "2"

成员顺序本身不代表依赖层级，但连续出现的 app-server-*、code-mode-* 和 ext/* 能帮助读者先找到专题边界。真正的边方向仍要交给 metadata resolve 图，而不能从列表相邻关系推断。

workspace 还统一了 package 元数据和内部 path dependency 的名称到路径映射：

源码位置：codex-rs/Cargo.toml :: [workspace.package], [workspace.dependencies]（节选）

toml

[workspace.package]
version = "0.150.0"
# 新 crate 默认继承 2024 edition，个别 crate 仍可在自己的 manifest 覆盖。
edition = "2024"
license = "Apache-2.0"

[workspace.dependencies]
# Internal
app_test_support = { path = "app-server/tests/common" }
codex-analytics = { path = "analytics" }
codex-agent-graph-store = { path = "agent-graph-store" }
codex-agent-identity = { path = "agent-identity" }
codex-ansi-escape = { path = "ansi-escape" }
codex-api = { path = "codex-api" }
codex-aws-auth = { path = "aws-auth" }
codex-app-server = { path = "app-server" }
codex-app-server-transport = { path = "app-server-transport" }
codex-app-server-daemon = { path = "app-server-daemon" }
codex-app-server-client = { path = "app-server-client" }
codex-app-server-protocol = { path = "app-server-protocol" }
codex-app-server-test-client = { path = "app-server-test-client" }
codex-apply-patch = { path = "apply-patch" }
codex-arg0 = { path = "arg0" }
codex-async-utils = { path = "async-utils" }
codex-backend-client = { path = "backend-client" }
codex-chatgpt = { path = "chatgpt" }
codex-cli = { path = "cli" }
codex-client = { path = "codex-client" }
codex-cloud-config = { path = "cloud-config" }
codex-code-mode = { path = "code-mode" }
codex-code-mode-protocol = { path = "code-mode-protocol" }
codex-code-mode-runtime = { path = "code-mode-runtime" }
codex-config = { path = "config" }
codex-connectors = { path = "connectors" }
codex-context-fragments = { path = "context-fragments" }
codex-core = { path = "core" }
codex-core-api = { path = "core-api" }
codex-core-plugins = { path = "core-plugins" }
codex-core-skills = { path = "core-skills" }
# ...

members 决定谁属于 workspace；workspace.dependencies 决定成员 manifest 使用的统一 dependency key。两者共同解释为什么 package 名、目录名和依赖名并不总是一一相同。

2. Manifest清单

[workspace].members 数组显式写了 136 个路径。另外 6 个 manifest 位于 workspace 根下、继承 version.workspace、edition.workspace 和 license.workspace，并被 workspace package 通过路径依赖或工程配置纳入。Cargo metadata 将它们一并列入 workspace_members。

metadata package	manifest 目录	角色
`app_test_support`	`app-server/tests/common/`	App Server 集成测试公共库
`codex-chatgpt`	`chatgpt/`	第一方 ChatGPT/Codex 产品能力
`core_test_support`	`core/tests/common/`	Core 集成测试公共库
`mcp_test_support`	`mcp-server/tests/common/`	MCP Server 集成测试公共库
`codex-message-history`	`message-history/`	本地消息历史持久化
`codex-windows-sandbox`	`windows-sandbox-rs/`	Windows sandbox 库与两个辅助二进制

因此，升级 tag 时不能只对 members = [...] 做文本 diff。新增一个位于 workspace 根内的路径 package，可能在没有增加数组行的情况下改变 metadata 清单。

3. Package与Target

Cargo package 是一个 manifest 边界；它可以同时产生 library、binary、integration test、example、 benchmark 或 build script target。该版本的 package target 组合如下：

cargo metadata 的对象关系解释了为什么目录数、package 数和 binary 数不能互换。下面的类型名对应 metadata 返回结构中的真实概念。

一个 Package 可以组合多个 Target，依赖边则挂在 package 而不是 binary 上。本文的 142 个节点因此来自 Metadata.packages，31 个含 binary 的 package 还会继续展开为更多 target。

target kind 组合	package 数	解读
`lib`	93	只有 library target；仍可在 `src` 内包含 unit tests
`lib+test`	15	library 加显式 integration-test target
`bin+lib+test`	11	同时提供库、二进制和 integration test
`bin+lib`	5	库和二进制
`bin+custom-build+lib+test`	2	CLI 或 Linux sandbox 还需要 build script
`proc-macro`	2	过程宏 package
`bench+lib`	1	图像工具库带 benchmark
`bin`	1	只有演示二进制
`bin+custom-build`	1	构建并输出捆绑 bubblewrap
`bin+custom-build+lib`	1	Windows sandbox 库、helper 二进制与 build script
`custom-build+lib`	1	skills 库在构建时准备内置资产
`example+lib`	1	config 库附带示例
`example+lib+test`	1	extension API 附带示例和显式测试

其中“31 个 package 包含 binary”不表示 Codex 对用户提供 31 个稳定命令。 codex-app-server、codex-rmcp-client 和 codex-tui 等 package 还包含测试服务器、fixture generator 或辅助调试 binary。产品入口要继续查看 targets[].name、CLI 分派和打包脚本。

三个短 manifest 片段可以校准 metadata 字段的真实含义。codex-core 同时生成 library 和 schema writer binary；codex-core-api 关闭自己的 test/doctest target；codex-backend-client 则显式禁止发布。

源码位置：codex-rs/core/Cargo.toml :: [lib], [[bin]]

toml

[lib]
name = "codex_core"
path = "src/lib.rs"

# package含bin不等于bin就是面向终端用户的稳定产品命令。
[[bin]]
name = "codex-write-config-schema"
path = "src/bin/config_schema.rs"

facade package 则展示另一种 lib target 配置：它依赖下游 consumer 编译验证，不创建自己的测试 harness。

源码位置：codex-rs/core-api/Cargo.toml :: [lib]

toml

[lib]
doctest = false
name = "codex_core_api"
path = "src/lib.rs"
# test=false只关闭该lib target的测试harness，不代表底层Core没有测试。
test = false

发布属性属于 package 元数据，与 target 组合正交。当前唯一显式关闭发布的 manifest 如下：

源码位置：codex-rs/backend-client/Cargo.toml :: [package]

toml

[package]
name = "codex-backend-client"
version.workspace = true
edition.workspace = true
license.workspace = true
# metadata中publish=[]来自这个显式配置。
publish = []

4. 按源码职责归类

完整矩阵按源码职责分成 16 类。跨模块概览和版本差异不直接对应某个 package；其余 package 按最主要的行为边界归类。

源码职责类	package 数	归类依据	常见交叉类
Multi-Agent	4	多 Agent 拓扑、协作模式与 Goal	Persistence、Extensions
App Server	7	App Server 服务、client、transport 与 daemon	Protocol、Core Runtime
Protocol	6	跨 crate/进程共享类型与路径 wire type	App Server、Execution
Execution	13	进程、PTY、文件、Code Mode 与 Exec Server	Tools、Security
Security	13	策略、沙箱、凭据、网络与进程强制	Execution、Config/Auth
CLI	9	顶层命令、非交互入口和云任务	Core Runtime、Model
Core Runtime	7	Thread/Turn 核心编排与通用异步基础	Context、Model
Model	14	provider、HTTP/SSE/WebSocket、本地模型与后端 API	Core Runtime、Config/Auth
Context	4	上下文片段、prompt、模板和预算截断	Core Runtime、Tools
Tools	2	模型可见工具合约与文件搜索	Execution、Extensions
Extensions	22	Plugin、Skill、Hook、Connector、MCP 与扩展 crate	Multi-Agent、Config/Auth
Persistence	7	Thread、rollout、memory、message 与 SQLite 持久化	Core Runtime、Observability
Config/Auth	11	配置层、feature、认证、CODEX_HOME 与安装环境	Security、CLI
Observability	6	analytics、OTel、feedback 和本地诊断	Core Runtime、Persistence
TUI	7	终端 UI、ANSI、媒体处理和休眠抑制	CLI、Core Runtime
Build/Test	3	跨 Cargo/Bazel 测试支持与 binary 定位	多个职责域

例如 codex-app-server-protocol 的内容是协议，但主要服务于 App Server；本矩阵将它放入 Protocol，App Server 文章通过交叉引用使用它。codex-agent-graph-store 则归 Multi-Agent，但其本地存储实现仍是 Persistence 的证据。这种“一个主要职责 + 多个交叉使用者”避免同一 crate 被重复解释。

5. Package覆盖矩阵

Target 列只列 metadata 中出现的 kind；test 指独立 test target，不包括编译在 library 内的 #[cfg(test)] unit test。路径全部相对 codex-rs/。

5.1 核心服务

Package	Manifest 路径	Target	直接职责	源码职责类
`codex-async-utils`	`async-utils`	`lib`	提供异步任务、取消与 channel 通用工具	Core Runtime
`codex-core-api`	`core-api`	`lib`	向产品入口暴露稳定的 Thread 管理 facade	Core Runtime
`codex-core`	`core`	`bin+lib+test`	实现 Session、Turn、模型循环与工具编排	Core Runtime
`codex-utils-cache`	`utils/cache`	`lib`	提供异步与阻塞 LRU 缓存辅助	Core Runtime
`codex-utils-readiness`	`utils/readiness`	`lib`	提供带授权 token 的异步就绪状态	Core Runtime
`codex-utils-string`	`utils/string`	`lib`	提供 JSON 字符串与 token 预算截断工具	Core Runtime
`codex-thread-manager-sample`	`thread-manager-sample`	`bin`	演示如何嵌入并调用 ThreadManager	Core Runtime
`codex-context-fragments`	`context-fragments`	`lib`	定义有界、可组合的模型上下文片段	Context
`codex-prompts`	`prompts`	`lib`	集中提供压缩、审查、权限与 Goal prompts	Context
`codex-utils-output-truncation`	`utils/output-truncation`	`lib`	按 token 或字符预算截断工具与执行输出	Context
`codex-utils-template`	`utils/template`	`lib`	严格解析并渲染文本模板占位符	Context
`codex-aws-auth`	`aws-auth`	`lib`	实现 AWS 凭据加载与 SigV4 请求签名	Model
`codex-backend-client`	`backend-client`	`lib`	封装 Codex 后端账户、任务与设置 API	Model
`codex-api`	`codex-api`	`lib+test`	实现 Responses、Compact 与 Memories 类型化 API	Model
`codex-backend-openapi-models`	`codex-backend-openapi-models`	`lib`	保存后端 OpenAPI 生成模型	Model
`codex-client`	`codex-client`	`lib`	提供通用 HTTP 重试、退避与 SSE 策略	Model
`codex-http-client`	`http-client`	`bin+lib+test`	提供路由感知、代理感知的底层 HTTP transport	Model
`codex-lmstudio`	`lmstudio`	`lib`	封装 LM Studio 本地模型发现与默认值	Model
`codex-model-provider-info`	`model-provider-info`	`lib`	管理内置及用户定义的模型 provider 配置	Model
`codex-model-provider`	`model-provider`	`lib`	定义模型 provider 运行接口与实现桥接	Model
`codex-models-manager`	`models-manager`	`lib`	加载、缓存并筛选模型目录与预设	Model
`codex-ollama`	`ollama`	`lib`	封装 Ollama 本地模型发现与默认值	Model
`codex-utils-oss`	`utils/oss`	`lib`	共享 TUI 和 Exec 的本地 OSS provider 选择逻辑	Model
`codex-utils-stream-parser`	`utils/stream-parser`	`lib`	增量解析流式文本、隐藏标签与引用	Model
`codex-websocket-client`	`websocket-client`	`lib`	提供带策略配置的 WebSocket client	Model
`codex-app-server-protocol-noop-macros`	`app-server-protocol-noop-macros`	`proc-macro`	在无需导出时提供 App Server 协议空过程宏	Protocol
`codex-app-server-protocol`	`app-server-protocol`	`lib`	定义 App Server 请求、响应、通知与 schema 导出	Protocol
`codex-experimental-api-macros`	`codex-experimental-api-macros`	`proc-macro`	标记并控制实验 API 的过程宏	Protocol
`codex-protocol`	`protocol`	`lib`	定义 Core 的 Op、Event、模型与配置协议类型	Protocol
`codex-utils-absolute-path`	`utils/absolute-path`	`lib`	提供已验证绝对路径类型与跨平台规范化	Protocol
`codex-utils-path-uri`	`utils/path-uri`	`lib`	提供可序列化的跨平台 file URI 路径类型	Protocol
`codex-app-server-client`	`app-server-client`	`lib`	供 TUI 与 Exec 复用进程内 App Server 客户端	App Server
`codex-app-server-daemon`	`app-server-daemon`	`lib`	管理 Unix App Server 守护进程生命周期	App Server
`codex-app-server-test-client`	`app-server-test-client`	`bin+lib`	提供独立 App Server 协议测试客户端	App Server
`codex-app-server-transport`	`app-server-transport`	`lib`	实现 stdio、WebSocket、UDS 与远程控制 transport	App Server
`codex-app-server`	`app-server`	`bin+lib+test`	实现 App Server 请求处理、状态与对外服务	App Server
`app_test_support`	`app-server/tests/common`	`lib`	共享 App Server 集成测试夹具与客户端	App Server
`codex-uds`	`uds`	`lib`	封装跨平台异步 Unix Domain Socket	App Server

5.2 入口与执行

Package	Manifest 路径	Target	直接职责	源码职责类
`codex-arg0`	`arg0`	`lib`	依据 argv0 或特殊参数分派内置辅助入口	CLI
`codex-chatgpt`	`chatgpt`	`lib+test`	封装第一方 ChatGPT/Codex 产品命令能力	CLI
`codex-cli`	`cli`	`bin+custom-build+lib+test`	定义顶层 `codex` 多命令入口与分派	CLI
`codex-cloud-tasks-client`	`cloud-tasks-client`	`lib`	定义云任务后端接口与 HTTP 客户端	CLI
`codex-cloud-tasks-mock-client`	`cloud-tasks-mock-client`	`lib`	提供云任务测试用 mock client	CLI
`codex-cloud-tasks`	`cloud-tasks`	`lib+test`	实现云任务列表、创建、应用与终端 UI	CLI
`codex-exec`	`exec`	`bin+lib+test`	实现非交互 `codex exec` 和 `review` 客户端	CLI
`codex-responses-api-proxy`	`responses-api-proxy`	`bin+lib`	提供 Responses API 本地代理进程	CLI
`codex-utils-cli`	`utils/cli`	`lib`	共享审批、沙箱、恢复和配置覆盖 CLI 参数	CLI
`codex-ansi-escape`	`ansi-escape`	`lib`	把 ANSI 输出转换为 ratatui 文本	TUI
`codex-terminal-detection`	`terminal-detection`	`lib`	识别终端类型并提供 TUI 和遥测元数据	TUI
`codex-tui`	`tui`	`bin+lib+test`	实现交互式终端应用、事件循环与组件	TUI
`codex-utils-audio`	`utils/audio`	`lib`	准备音频模型输入并估算 token	TUI
`codex-utils-fuzzy-match`	`utils/fuzzy-match`	`lib`	提供 Unicode 安全的模糊匹配与高亮	TUI
`codex-utils-image`	`utils/image`	`bench+lib`	解码、缩放、缓存并规范化图像输入	TUI
`codex-utils-sleep-inhibitor`	`utils/sleep-inhibitor`	`lib`	在 Turn 运行期间跨平台阻止系统休眠	TUI
`codex-file-search`	`file-search`	`bin+lib`	按 gitignore 遍历并模糊搜索工作区文件	Tools
`codex-tools`	`tools`	`lib+test`	定义共享 ToolSpec、ToolExecutor 与工具适配器	Tools
`codex-apply-patch`	`apply-patch`	`bin+lib+test`	解析、验证并应用 `apply_patch` 补丁	Execution
`codex-code-mode-host`	`code-mode-host`	`bin+lib+test`	托管独立 Code Mode V8 会话与传输	Execution
`codex-code-mode-protocol`	`code-mode-protocol`	`lib`	定义 Code Mode host、runtime 与 cell 协议	Execution
`codex-code-mode-runtime`	`code-mode-runtime`	`lib+test`	实现进程内 V8 Code Mode cell runtime	Execution
`codex-code-mode`	`code-mode`	`lib`	选择进程内、进程拥有或远程 Code Mode 会话	Execution
`codex-exec-server-protocol`	`exec-server-protocol`	`lib`	定义远程进程、文件与 HTTP 执行协议	Execution
`codex-exec-server`	`exec-server`	`lib+test`	实现本地或远程执行环境服务	Execution
`codex-exec-server-test-support`	`exec-server/tests/support`	`lib`	共享 Exec Server 集成测试环境	Execution
`codex-file-system`	`file-system`	`lib`	实现执行环境文件系统与权限模型	Execution
`codex-git-utils`	`git-utils`	`lib`	提供 Git 根目录、分支、diff 与仓库操作	Execution
`codex-utils-path`	`utils/path-utils`	`lib`	提供路径规范化、符号链接解析与原子写入	Execution
`codex-utils-pty`	`utils/pty`	`lib`	统一 PTY 与 pipe 子进程控制	Execution
`codex-v8-poc`	`v8-poc`	`lib`	验证 V8 嵌入与沙箱能力的实验库	Execution
`codex-agent-identity`	`agent-identity`	`lib`	生成、注册并验证 Agent 身份密钥与令牌	Security
`codex-bwrap`	`bwrap`	`bin+custom-build`	构建随发行包交付的 bubblewrap 二进制	Security
`codex-execpolicy`	`execpolicy`	`bin+lib+test`	用 Starlark 前缀规则判定命令执行策略	Security
`codex-linux-sandbox`	`linux-sandbox`	`bin+custom-build+lib+test`	实现 Linux Landlock 与 bubblewrap 沙箱入口	Security
`codex-network-proxy`	`network-proxy`	`lib+test`	实现受策略约束的网络代理与请求转发	Security
`codex-process-hardening`	`process-hardening`	`lib`	应用平台进程加固与危险能力收缩	Security
`codex-sandboxing`	`sandboxing`	`lib`	共享沙箱策略转换与命令构造	Security
`codex-secrets`	`secrets`	`lib`	识别、包装并安全处理敏感值	Security
`codex-shell-command`	`shell-command`	`lib`	解析 shell 命令并提取安全判定信息	Security
`codex-shell-escalation`	`shell-escalation`	`bin+lib`	实现 execve 包装与 shell 权限提升链路	Security
`codex-utils-rustls-provider`	`utils/rustls-provider`	`lib+test`	安装进程级 rustls 加密 provider	Security
`codex-utils-sandbox-summary`	`utils/sandbox-summary`	`lib`	把权限配置与沙箱策略转为可读摘要	Security
`codex-windows-sandbox`	`windows-sandbox-rs`	`bin+custom-build+lib`	实现 Windows 沙箱服务、runner 与 setup 工具	Security

5.3 扩展与配置

Package	Manifest 路径	Target	直接职责	源码职责类
`codex-mcp`	`codex-mcp`	`lib`	编排 MCP runtime、目录、资源与 elicitation	Extensions
`codex-connectors`	`connectors`	`lib`	管理 App connector 元数据、策略与 runtime	Extensions
`codex-core-plugins`	`core-plugins`	`lib`	加载、同步并管理 marketplace 和 plugin 生命周期	Extensions
`codex-core-skills`	`core-skills`	`lib+test`	加载、过滤并注入产品可见 skills	Extensions
`codex-connectors-extension`	`ext/connectors`	`lib`	把 connectors 暴露为扩展能力	Extensions
`codex-extension-api`	`ext/extension-api`	`example+lib+test`	定义扩展注册、发现与执行公共 API	Extensions
`codex-git-attribution`	`ext/git-attribution`	`lib`	提供扩展脚本和变更的 Git 归因	Extensions
`codex-guardian`	`ext/guardian`	`lib`	提供 Guardian 审查扩展与策略桥接	Extensions
`codex-image-generation-extension`	`ext/image-generation`	`lib`	实现图像生成扩展工具	Extensions
`codex-extension-items`	`ext/items`	`lib`	定义扩展共享 item 类型	Extensions
`codex-mcp-extension`	`ext/mcp`	`lib+test`	把 MCP 能力注册为扩展	Extensions
`codex-skills-extension`	`ext/skills`	`lib+test`	把 skill 发现与读取注册为扩展	Extensions
`codex-web-search-extension`	`ext/web-search`	`lib`	实现 Web Search 扩展工具	Extensions
`codex-external-agent-migration`	`external-agent-migration`	`lib`	检测并迁移外部 Agent 配置与会话	Extensions
`codex-hooks`	`hooks`	`bin+lib`	定义 hook 声明、事件、执行引擎与 schema	Extensions
`codex-mcp-server`	`mcp-server`	`bin+lib+test`	把 Codex 暴露为 MCP server	Extensions
`mcp_test_support`	`mcp-server/tests/common`	`lib`	共享 MCP Server 集成测试夹具	Extensions
`codex-plugin`	`plugin`	`lib`	定义 plugin 包、标识、来源与解析模型	Extensions
`codex-rmcp-client`	`rmcp-client`	`bin+lib+test`	实现 MCP transport、OAuth 与协议模式客户端	Extensions
`codex-skills`	`skills`	`custom-build+lib`	实现底层 skill 扫描、索引和隐式匹配	Extensions
`codex-stdio-to-uds`	`stdio-to-uds`	`bin+lib+test`	在 MCP stdio 与 Unix Socket 之间转接	Extensions
`codex-utils-plugins`	`utils/plugins`	`lib`	共享 plugin 路径、mention 与 connector 工具	Extensions
`codex-agent-graph-store`	`agent-graph-store`	`lib`	存储由线程派生的父子 Agent 拓扑	Multi-Agent
`codex-collaboration-mode-templates`	`collaboration-mode-templates`	`lib`	编译内置默认与计划协作模式模板	Multi-Agent
`codex-agent-extension`	`ext/agent`	`lib+test`	提供 Agent 扩展及多 Agent 工具桥接	Multi-Agent
`codex-goal-extension`	`ext/goal`	`lib+test`	提供 Goal 扩展的读取与更新能力	Multi-Agent
`codex-memories-extension`	`ext/memories`	`lib`	把 memory 能力注册为扩展	Persistence
`codex-memories-read`	`memories/read`	`lib`	注入记忆指令并解析 memory citations	Persistence
`codex-memories-write`	`memories/write`	`lib`	实现两阶段记忆提取与合并辅助	Persistence
`codex-message-history`	`message-history`	`lib`	持久化并读取本地消息历史	Persistence
`codex-rollout`	`rollout`	`lib`	记录、发现、压缩并维护会话 JSONL	Persistence
`codex-state`	`state`	`lib`	用 SQLite 镜像 rollout 元数据与作业状态	Persistence
`codex-thread-store`	`thread-store`	`lib`	抽象 Thread 历史与元数据存储边界	Persistence
`codex-cloud-config`	`cloud-config`	`lib`	加载、验证、缓存并刷新云端配置	Config/Auth
`codex-config`	`config`	`example+lib`	解析并合并多层 Codex 配置	Config/Auth
`codex-features`	`features`	`lib`	集中注册并解析 feature flags	Config/Auth
`codex-file-watcher`	`file-watcher`	`lib`	订阅文件变化并按所有者路由通知	Config/Auth
`codex-home`	`codex-home`	`lib`	定位和管理 `CODEX_HOME` 目录边界	Config/Auth
`codex-install-context`	`install-context`	`lib`	识别 standalone package 布局与安装方式	Config/Auth
`codex-keyring-store`	`keyring-store`	`lib`	通过系统 keyring 保存凭据	Config/Auth
`codex-login`	`login`	`lib+test`	实现 API key、ChatGPT 与设备码认证	Config/Auth
`codex-utils-approval-presets`	`utils/approval-presets`	`lib`	组合内置审批策略与权限 profile	Config/Auth
`codex-utils-home-dir`	`utils/home-dir`	`lib`	解析并校验 `CODEX_HOME` 与用户目录	Config/Auth
`codex-utils-json-to-toml`	`utils/json-to-toml`	`lib`	把 JSON 配置值转换为 TOML	Config/Auth
`codex-analytics`	`analytics`	`lib`	归约并发送 Codex 产品分析事件	Observability
`codex-feedback`	`feedback`	`lib`	收集、打包并上传用户反馈附件	Observability
`codex-otel`	`otel`	`lib+test`	配置日志、指标与 OpenTelemetry 导出	Observability
`codex-response-debug-context`	`response-debug-context`	`lib`	从 API 错误提取请求与代理诊断头	Observability
`codex-rollout-trace`	`rollout-trace`	`lib`	记录并离线归约本地 rollout 调试图	Observability
`codex-utils-elapsed`	`utils/elapsed`	`lib`	格式化紧凑的人类可读耗时	Observability

5.4 测试基础设施

Package	Manifest 路径	Target	直接职责	源码职责类
`core_test_support`	`core/tests/common`	`lib`	共享 Core 集成测试服务器、fixture 与 builder	Build/Test
`codex-test-binary-support`	`test-binary-support`	`lib`	提供测试辅助二进制的共享实现	Build/Test
`codex-utils-cargo-bin`	`utils/cargo-bin`	`lib`	统一 Cargo/Bazel 测试二进制与 runfile 定位	Build/Test

6. 升级矩阵

矩阵的可维护单元是 package name，而不是行号或当前排序位置。跟进新 tag 时，先比较 metadata 集合，再审查变更 package 的 manifest、target 和职责：

新增一个 utils/ package 可能只改变一个局部 consumer；删除 codex-protocol 或改变 codex-core target 则会影响多条依赖链。package 集合、manifest diff 和依赖图三者结合，才能判断实际影响范围。

7. 重建全部统计

以下命令重新执行 metadata 查询，结果用于生成本文矩阵。以下命令均从 Codex 仓库根运行，--no-deps 明确只研究 workspace package，不把 crates.io 节点加入清单。

bash

# 生成一次metadata；临时文件不属于仓库资产。
cargo metadata --manifest-path codex-rs/Cargo.toml \
  --no-deps --format-version 1 > /tmp/codex-metadata.json

# package/member、target形态和统一元数据。
jq '{
  packages: (.packages | length),
  members: (.workspace_members | length),
  defaults: (.workspace_default_members | length),
  with_bin: ([.packages[] | select(any(.targets[]; .kind | index("bin")))] | length),
  proc_macro: ([.packages[] | select(any(.targets[]; .kind | index("proc-macro")))] | length),
  custom_build: ([.packages[] | select(any(.targets[]; .kind | index("custom-build")))] | length),
  explicit_test: ([.packages[] | select(any(.targets[]; .kind | index("test")))] | length),
  versions: ([.packages[].version] | unique),
  editions: ([.packages[].edition] | unique),
  licenses: ([.packages[].license] | unique),
  publish_false: [.packages[] | select(.publish == []) | .name]
}' /tmp/codex-metadata.json

# manifest文本中显式member路径数；Cargo还会纳入workspace根内路径package。
python3 -c 'import pathlib,tomllib; d=tomllib.loads(pathlib.Path("codex-rs/Cargo.toml").read_text()); print(len(d["workspace"]["members"]))'

# 按每个package的target kind并集分组，重建第3节表格。
jq '[.packages[] | ([.targets[].kind[]] | unique | sort | join("+"))]
    | group_by(.) | map({kind: .[0], count: length}) | sort_by(-.count)' \
  /tmp/codex-metadata.json

查询结果	数值
packages / members / defaults	142 / 142 / 142
含 bin / proc-macro / custom-build / explicit test 的 package	31 / 2 / 6 / 32
unique version / edition / license	`0.150.0` / `2024` / `Apache-2.0`
显式 `workspace.members` 路径	136
`publish = []`	仅 `codex-backend-client`

这里的 explicit_test=29 只统计 metadata target，不包含 library 内的 #[cfg(test)]；with_bin=21 也只说明存在 binary target，不说明打包脚本会交付它。升级时若数字变化，应继续查看 package name、manifest path 和 target name 的集合 diff，而不是只修改总数。

7.1 统计适用范围

重建命令的输入是 workspace manifest，动作是让 Cargo 输出 package、member 和 target 集合，再用 jq 按字段归约；关键断言是三组数量相等、版本/edition/license 各只有一个值，以及 package 集合与正文矩阵的差集为空。它能证明当前 workspace 的静态清单与矩阵一致，不能证明依赖方向、代码是否真的使用某个 target，也不能证明 binary 会被打包进某个平台安装包。需要回答后两个问题时，分别转到 Crate依赖边界和对应的构建/发布源码。

8. Package专题

已定位的package或问题	对应专题正文	停止查矩阵的条件
`codex-core`、`codex-core-api`	Core与Core-API边界	已确定宿主facade或内部实现
`codex-core` 内的Thread/Turn	Core运行时架构总览	开始追踪状态与调用链
`thread-manager-sample`、manager依赖	ThreadManager依赖	已定位manager owner
`app-server-*`、TUI、Exec、Build/Test	Codex 产品形态全景	已确定连接寿命和transport
crate真实依赖方向	Crate依赖边界	需要回答“谁依赖谁”
sandbox、exec、platform package	Codex信任边界、跨平台能力矩阵	已选定强制后端与平台
feature/config package	Core运行时能力开关	开始分析effective gate
test/support/schema target	源码测试与生成物地图	已找到具体测试或generator
新tag改变了哪些consumer	Codex源码阅读路线	已定位受影响的调用链

本矩阵给 package 分配源码职责类只是导航。例如 codex-app-server-protocol 归 Protocol，不表示 App Server 不能消费它；真实依赖边和稳定边界以 Crate依赖边界的 metadata resolve 图为准。

Cargo 工作空间全景 ​

1. Cargo metadata ​

2. Manifest清单 ​

3. Package与Target ​

4. 按源码职责归类 ​

5. Package覆盖矩阵 ​

5.1 核心服务 ​

5.2 入口与执行 ​

5.3 扩展与配置 ​

5.4 测试基础设施 ​

6. 升级矩阵 ​

7. 重建全部统计 ​

7.1 统计适用范围 ​

8. Package专题 ​

Cargo 工作空间全景

1. Cargo metadata

2. Manifest清单

3. Package与Target

4. 按源码职责归类

5. Package覆盖矩阵

5.1 核心服务

5.2 入口与执行

5.3 扩展与配置

5.4 测试基础设施

6. 升级矩阵

7. 重建全部统计

7.1 统计适用范围

8. Package专题