测试、夹具与开发者验证工具
测试、夹具与开发者验证工具 stage-23（横切基础设施）
这一阶段像整个仓库的“总验收场”，不直接服务用户，而是在开机、聊天处理、工具执行、界面显示、保存收尾这些环节旁边反复试车。App-server 测协议和整条服务流程；Core 测会话、工具、安全边界；CLI、登录、MCP 测命令入口和开发者流程；exec-server 测远程传输、文件和沙箱；TUI 测终端画面和交互；共享库测试盯遥测、配置、路径、状态等底座。test-binary-support 还帮测试程序换“马甲”启动，安全地检查不同入口行为。
子阶段
本阶段涉及的状态1
reg-local-state-runtime本地 SQLite 和 StateRuntime 打开的那套持久化句柄，负责让线程、日志、目标、记忆等数据能长期保存。
测试、夹具与开发者验证工具
test-binary-support/lib.rs源码 ↗
有些程序会看自己是用什么名字启动的，也就是 argv0（启动命令里的第 0 个参数，通常是程序文件名），然后决定走哪条逻辑。这个文件就是为了在测试里安全地模拟这种情况。它会先看当前测试二进制文件的名字和第一个参数，再交给外部传进来的 classify 函数判断：是只做一次按名字分发、完全跳过，还是安装一组测试用的别名。安装别名时，它会临时创建一个 CODEX_HOME 目录，相当于给测试准备一个隔离的小房间；然后短暂改环境变量 CODEX_HOME，让别名安装到这个临时位置；装完后马上把原来的环境变量恢复。TestBinaryDispatchGuard 像一张“保管票”，拿着它，临时目录和别名路径就还有效；丢掉它时，临时资源也会跟着清理。
TestBinaryDispatchGuard::paths15–17 ↗
fn paths(&self) -> &Arg0DispatchPaths作用：这个函数让测试代码拿到刚才创建好的“按启动名字分发”的路径信息。简单说，它把保存在 guard 里的测试别名路径拿出来给别人看。
数据流：进去的是一个已经创建好的 TestBinaryDispatchGuard → 它读取里面保存的 arg0 分发守卫 → 返回一份 Arg0DispatchPaths 的引用，也就是测试别名和相关路径的信息；它不创建新东西，也不修改状态。
调用关系：它是 TestBinaryDispatchGuard 对外开的一个小窗口。configure_test_binary_dispatch 成功安装测试别名后会返回这个 guard，后续测试如果需要知道别名装在哪里，就会调用 TestBinaryDispatchGuard::paths；它内部只是把请求转给 arg0 里的 paths 方法。
调用图：调用 1 个内部函数（paths）。
configure_test_binary_dispatch26–77 ↗
fn configure_test_binary_dispatch(
codex_home_prefix: &str,
classify: F,
) -> Option<TestBinaryDispatchGuard>作用：这个函数是测试启动时的总开关：它判断当前测试程序应该不应该启用“按程序名分发”的测试别名。需要启用时，它会搭好临时目录、临时改环境变量、安装别名，并返回一个 guard 来维持这些测试资源。
数据流：进去的是一个临时 CODEX_HOME 目录名前缀，以及一个 classify 判断函数 → 它读取当前进程的启动参数，拿到程序名和第一个参数，让 classify 决定模式 → 如果是 DispatchArg0Only，就只调用 arg0_dispatch 做一次分发并返回 None；如果是 Skip，就什么也不做返回 None；如果是 InstallAliases，就创建临时目录，保存旧的 CODEX_HOME，把 CODEX_HOME 暂时指向临时目录，调用 arg0_dispatch 安装测试别名，再恢复原来的 CODEX_HOME，最后返回装着临时目录和路径信息的 TestBinaryDispatchGuard。失败时会直接 panic，也就是让测试立刻报错停止。
调用关系：它通常在测试二进制刚启动、测试线程还没跑起来之前调用，因为它会改环境变量。它负责串起几个外部动作：读取命令行参数、创建临时目录、读写环境变量、调用 arg0_dispatch 建立按 argv0 分发的别名。TestBinaryDispatchGuard::paths 之后可以读取它安装出来的路径。
调用图：外部调用 8 个（new, arg0_dispatch, panic!, args_os, remove_var, set_var, var_os, new）。