# 上游对齐：openai/codex 稳定版 0.164.0（核查日 2026-10-27）

结论先说：**有更新，但本项目不追 alpha，只锚定稳定版。**

## 基线与上游位置

- 本项目此前锚定：`codex-cli 0.164.0-alpha.9`（2026-10-25 实测，`protocol/` 的
  schema 就是从它用 `codex app-server generate-json-schema` 导出的）。
- 上游稳定版：`0.164.0`，2026-10-23 发布，由 `0.164.0-alpha.11` 加一个发布提交
  切出，相对 0.163.0 约 330 个提交。也就是说本地 alpha.9 比稳定版落后
  alpha.10、alpha.11 两个 alpha 切片加稳定提交，不是落后一个大版本。
- 上游 alpha 线（不作为目标）：0.165.0-alpha.1（2026-10-23，含
  `reasoning_effort_override` 转 stable）→ 0.165.0-alpha.3 → 0.166.0-alpha.1。
  alpha 线 4 天内连跳两个小版本，追它等于每几天重 pin 一次，
  与宿主“版本由部署显式控制”的原则冲突，故只记录、不跟进。
- 上游来源：https://github.com/openai/codex/releases

## 稳定版 0.164.0 改动 → 本项目状态

| 上游改动 | 对宿主层的影响 | 结论 |
|---|---|---|
| `/presets` 十个可复用提示槽、`/model` 与 `/permissions` 行内参数、终端图片预览 | 都是 TUI 交互面，app-server 协议与宿主层不依赖它们；控制台已有模型/强度下拉（#59） | 不相关，无需改代码 |
| 恢复会话时找回压缩历史、恢复已保存的线程设置（不再被全局默认覆盖） | 宿主每次回合都显式传 model/effort/sandbox，`thread/resume` 本就存在；上游修的是“恢复后被重置”这一坑 | 已兼容，换稳定版二进制后需重测 resume 一项，不改代码 |
| 排队提示等挂起的权限选择解决后再继续 | 宿主后续消息本来就是排队语义（#65：排队不打断当前轮，跑完按序再跑；direct 优先于排队） | 已覆盖，语义与上游一致 |
| 后台服务磁盘清理：剪掉未用的 daemon 发布、给 daemon 日志设上限、修 daemon 更新器 socket | 本项目不用 managed daemon：`start.sh` 直接拉起 app-server，worker 也是显式拉起 | 需防“被动启用”：见下文配置改动 |
| 远程 Bash / Zsh 会话中的凭据掩码、企业 MCP 认证 | 宿主走中继 provider，不用企业 MCP；远程 exec-server 不是生产路径 | 不相关，列为观察项 |
| 沙箱加固：macOS 大小写变体元数据路径、可替换 symlink 定位可执行文件 | 生产是 Linux + Docker 外层隔离 + 容器内 danger-full-access，macOS 沙箱路径不适用 | 不相关 |
| `worktrees` / `realtime_conversation` 等 feature flag 被移除、功能保持开启 | 宿主的 git worktree 编排不依赖这些 flag | 无需改代码 |
| Bedrock 设置向导默认开启 | 宿主不走 Bedrock | 不相关 |
| Windows HTTPS / WebSocket 代理认证、CLI 多层 `-c` 覆盖保留 | 宿主跑在 Linux，Windows 路径不适用 | 不相关 |

## 更早已覆盖的上游能力（不是本次新发现的缺口）

- 0.159：app-server 客户端可从指定 item 分页拉线程历史。
  alpha.9 的 schema 里已有 `thread/turns/list`、`thread/items/list`、
  `ThreadItemsListCursor`，且 `ThreadReadParams` 明确写着“完整历史
  hydration 已废弃，优先元数据读取 + 分页”。宿主用的是实时事件流 +
  `thread/list`，不做全量历史 hydration，这是有意的设计，不是缺口。
- 0.163：运行中发后续消息 steering、中断同时停 Code Mode 单元、
  并行只读工具。宿主 #65 的 followup/direct、#65 的 fork、host 的
  `turn/interrupt` 跨进程中断已覆盖对应语义。
- 0.165 alpha：`reasoning_effort_override` 转 stable。宿主每任务已有
  effort 档位校验（low/medium/high/xhigh/max）并透传给 turn，
  不需要为这个 flag 改代码。

## 本批实际改动（只改宿主侧，不动官方二进制）

1. `config.example.toml`：新增 `[features] daemon_auto_start = false`，
   并写明原因。自 0.157 起交互式 codex 默认启动 managed daemon，
   5 分钟后首次检查、每小时检查更新并重启服务，可在回合进行中
   中断任务，还会把版本控制权从宿主手里拿走。宿主托管的机器上
   绝不能让一次交互式 `codex` 启动悄悄换掉 pin 住的版本。
   这是本次对齐里唯一“不改就会在未来某天出事”的项。
2. `README.md` / `CHANGELOG.md`：把“锚定 alpha.9”改成“锚定稳定版
   0.164.0，alpha 线只记录不追”，并说明 `protocol/` 的 schema
   仍以 alpha.9 导出为准——没有新二进制就声称 schema 已更新是假话。
3. 本文件：作为 0.164.0 的对齐记录，后续每次上游稳定版发布时
   按同一张表复核。

## 明确不做的事（诚实边界）

- **不把 bin/ 或生产主机的 codex 二进制换成稳定版 0.164.0。**
  bin/ 在 `.gitignore` 里，生产主机的 codex 是主机侧 npm 安装，
  都不在本仓库的提交里；换二进制是部署动作，需要在主机侧
  显式执行并重跑 resume / goal / 成本实弹，不是改几行文档就能宣称的。
- **不追 0.165 / 0.166 alpha。** 等它们出稳定版再按本文件复核。
- **不重导 `protocol/` schema。** 本地二进制仍是 alpha.9，
  用它重导只会得到同一份 schema；等稳定版二进制到位后再重导并
  diff，diff 为空或只有新增字段时才能合并。
- **不合并、不部署。** 本批留在隔离 worktree 的 `feat-upstream-164`
  分支上；主 checkout 当时是脏的 feat-repo-picker 分支，绝不能
  从它推；生产仍在 0a862c1（#74），#75/#76/#77 也还没上生产，
  上游对齐与生产部署是两件分开的决策。

## 下一步（需要用户定）

1. 是否把本批提 PR（只含文档 + 配置示例 + 本文件，不含二进制变更）？
2. 是否另起一次主机侧部署，把 codex 从 alpha.9 升到稳定版 0.164.0，
   并重跑 resume / goal / 成本实弹？那一步需要主机部署凭证，
   且应与 #75/#76/#77 的生产部署放在同一批决策里看，而不是悄悄混进去。