host
972203c38f
- cloud/mcp_server.py：stdio MCP 服务，把云端任务 REST 翻成 tools/list / tools/call（health、list_projects、list_tasks、 get_task、create_task、cancel_task、get_task_cost、 get_task_trace），底层只走已有 REST，不另开任务逻辑； 鉴权只认调用方自己的 CODEX_CLOUD_API_KEY（缺了启动失败， 绝不打印），服务端权限 403 原样透传；create_task 只传已知 字段，未知字段丢弃；REST 报错时 isError=true。 单测 test_mcp_server 9 项（假 transport，不联网、不碰真 key）。 - 上游对齐 #80 的可合部分：config.example.toml 加 [features] daemon_auto_start = false（防 managed daemon 绕过 版本 pin）+ docs/upstream-164-alignment.md 对齐表；换稳定版 二进制是另一次主机侧部署动作，本批不做、不谎称已升级。
6.0 KiB
6.0 KiB
上游对齐：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 改代码。
本批实际改动（只改宿主侧，不动官方二进制）
config.example.toml：新增[features] daemon_auto_start = false， 并写明原因。自 0.157 起交互式 codex 默认启动 managed daemon， 5 分钟后首次检查、每小时检查更新并重启服务，可在回合进行中 中断任务，还会把版本控制权从宿主手里拿走。宿主托管的机器上 绝不能让一次交互式codex启动悄悄换掉 pin 住的版本。 这是本次对齐里唯一“不改就会在未来某天出事”的项。README.md/CHANGELOG.md：把“锚定 alpha.9”改成“锚定稳定版 0.164.0，alpha 线只记录不追”，并说明protocol/的 schema 仍以 alpha.9 导出为准——没有新二进制就声称 schema 已更新是假话。- 本文件：作为 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 也还没上生产， 上游对齐与生产部署是两件分开的决策。
下一步（需要用户定）
- 是否把本批提 PR（只含文档 + 配置示例 + 本文件，不含二进制变更）？
- 是否另起一次主机侧部署，把 codex 从 alpha.9 升到稳定版 0.164.0， 并重跑 resume / goal / 成本实弹？那一步需要主机部署凭证， 且应与 #75/#76/#77 的生产部署放在同一批决策里看，而不是悄悄混进去。