E2E verify on real Windows: codex accepts CODEX_HOME overlay and registers the bili MCP server (#681 / PR #683)

[ranxianglei]

来源: #681 修复 PR #683 的审查结论。

缺口

PR #683 把 Windows 上的 [mcp_servers.bili] 投递从内联 -c 改为 <CODEX_HOME>-bili overlay 的合并 config.toml(prepareCodexHome → CODEX_HOME 环境变量指向 overlay)。CI 已覆盖机制级测试(overlay 构建、块替换、兄弟目录共享、真 home 不动、win32 门控、启动集成),全绿。

但**"codex 本身接受 CODEX_HOME 覆盖层并从中注册 bili MCP server"这个行为只能真机 Windows 验证**:

1. codex 是否在 CODEX_HOME 指向 overlay 时正常启动(auth.json / sessions / 模型配置经共享条目可达)
2. [mcp_servers.bili] 是否真的注册(客户端内能看到 bili MCP 工具/compress 工具)
3. BILI_MCP_PROXY / BILI_CONVERSATION_ID 环境是否生效(代理侧出现对应会话)
4. 典型场景:node 装在 C:\Program Files\nodejs\(带空格路径)+ codex 为 npm .cmd shim → 修复前内联 -c 必坏、修复后应正常

验收

• 真机 Windows(建议 stock node 路径 + npm 安装的 codex)跑 bili codex
• 确认 MCP 工具注册、压缩工具可见、代理会话出现
• 并发开两个 bili codex 窗口:确认 livePidHoldsOverlay 警告出现、单窗口行为正常(已知限制:共享 overlay 后写者的 BILI_CONVERSATION_ID 获胜)
• 结果回填本 issue;若 codex 拒绝 overlay,回到 [bug] Windows: codex MCP injection -c value loses its quotes through cmd.exe when node lives under a spaced path #681 讨论替代投递方式

关联

• [bug] Windows: codex MCP injection -c value loses its quotes through cmd.exe when node lives under a spaced path #681(原 bug:cmd.exe 剥引号 → 内联 -c TOML 必坏)
• fix: deliver codex MCP server via CODEX_HOME overlay on Windows (#681) #683(修复 PR)

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

先说结论：我是跑在 Linux 上的 agent，无法在这个环境里直接驱动真实 Windows 的 codex（CLI/REPL），所以"真机 Windows 上 codex 接受 overlay 并注册 bili MCP server"这一步我没法替你点完。但我把能做的全做了：静态确认修复已合入且与 #679 共存正常、用真实代码跑了机制级验证、并对 #681 的核心（空格路径）给出了可复现的 TOML 有效性证明。下面分三块。

一、我在本机（Linux，真实代码）已验证的部分

• master 已含 fix: deliver codex MCP server via CODEX_HOME overlay on Windows (#681) #683 修复（合并提交 99fa258），并且确认没有把 [bug] Windows: a space in the client or -e path truncates the launch (spawn shell:true, unquoted) — and silently kills compression when only the command is quoted #679 冲掉——planClientSpawn / quoteWinToken / buildWindowsCommandLine 都还在 src/launcher.ts，runClient 仍走 planClientSpawn。fix: deliver codex MCP server via CODEX_HOME overlay on Windows (#681) #683 只是把 win32 分支的内联 -c 换成了 overlay，两者正交共存。
• typecheck clean / build success / tests/launcher.test.ts 109/109 全绿（含 PR 新增的 overlay 构建、块替换、兄弟目录共享、真 home 不动、win32 门控、启动集成）。
• 直接驱动真实的 prepareCodexHome(fakeHome, origin, convId)：overlay = <home>-bili；auth.json 与 sessions 是指回真 home 的符号链接（共享可达）；config.toml 是生成的合并文件，旧的 [mcp_servers.bili] 被替换为恰好 1 个新块；写了 .bili-launch.pid 标记（并发窗口告警用的就是它）。
• TOML 有效性证明（[bug] Windows: codex MCP injection -c value loses its quotes through cmd.exe when node lives under a spaced path #681 的核心）：用 Python tomllib 校验了 (a) 真实 prepareCodexHome 产物、(b) 按 mergeCodexBiliBlock 逐行复刻的空格 Windows 路径块 command = "C:\\Program Files\\nodejs\\node.exe" —— 两者都是合法 TOML，[mcp_servers.bili] 只出现 1 次，C:\Program Files\... 路径完整往返不丢字符。

二、层次判断：为什么这个修复是治本而不是治标

• [bug] Windows: codex MCP injection -c value loses its quotes through cmd.exe when node lives under a spaced path #681 根因：cmd.exe 会剥掉内联 -c mcp_servers.bili.command="..." 里 TOML 必需的引号，而任何 Windows 绝对路径都必须带引号 → 内联 -c 对任意 Windows 路径必坏，stock C:\Program Files\nodejs\node.exe 只是最常见触发点。
• 修复层次：把值写进 config.toml 文件（JSON.stringify → 合法 TOML basic string），codex 直接读文件，完全绕开 cmd 的参数解析。所以空格/反斜杠都不再是问题——这正是上面 tomllib 证明的东西。它打的正是"投递通道经过 cmd 引号语义"这个根因，不是去给路径打补丁。
• "codex 接受 overlay"的前提：codex 官方支持 CODEX_HOME 指向任意目录；overlay 里除 config.toml（合并生成）外，其余条目（auth.json/sessions/模型配置）全部通过符号链接/junction 指回真 home。所以登录态、会话、模型配置在 overlay 下都可达——这是 codex 能正常启动 + 注册 bili 的结构基础。这一层只有真机 codex 能最终背书，见下面第三块。

三、真机 Windows 验收步骤（可直接照抄，覆盖 issue 全部 4 项）

前置：一台 Windows（建议 node 就装在 stock C:\Program Files\nodejs\，codex 用 npm 装的 .cmd shim），npm i -g billion-context@latest，已 codex login 过一次（保证 ~/.codex/auth.json 存在）。

验收 1+2（MCP 注册 + compress 工具可见）——headless，不需要模型上游：

bili codex mcp list        # bili 起代理并把 CODEX_HOME 指向 overlay，再把 mcp list 转发给 codex
bili codex mcp get bili    # 看 command/args/env 是否就是 overlay 里写的那份

预期：列表里出现 bili，get 显示的 command 指向当前 node、env 带 BILI_MCP_PROXY/BILI_CONVERSATION_ID。（若你的 codex 版本子命令不同，进 REPL bili codex 后用 /mcp 看。）
再看代理侧会话：bili 启动时会打印 proxy log 路径，grep <你的 conversation id> 该日志确认请求确实进来。交互式验证 compress 工具：bili codex 进 REPL 让 agent 调一次压缩，确认工具存在且代理侧出现对应会话。

验收 3（并发两窗口）：同时开两个 bili codex（各起一个会话）。第二个窗口应打印 livePidHoldsOverlay 警告（overlay 被另一个存活进程占用）；单窗口行为正常。已知限制：共享 overlay 后写者的 BILI_CONVERSATION_ID 获胜——记录该行为即可，不算失败。

验收 4（典型场景）：确保 node 在 C:\Program Files\nodejs\ 且 codex 是 .cmd shim，然后跑上面的 headless 检查。修复前内联 -c 在这里必坏（TOML 解析错误 / bili 不注册），修复后应正常——这正是本 issue 要确认的核心。若 codex 拒绝 overlay，请回填现象，我们回 #681 讨论替代投递方式。

四、自动化建议（明确推荐，非选择题）

我建议加一个 windows-latest 的 CI job专门做 headless 的 codex mcp list 校验（不需要 E2E_UPSTREAM_* secrets，因为 mcp list 不触达模型），把 #686 固化成回归，避免以后回归时没人发现。真正跑模型往返的那部分维持现有 ubuntu e2e + manual dispatch。我会先把脚本 + workflow 草稿写好并开一个引用 #686 的 PR，是否合入 CI 由你拍板。

一句话总结：修复已合入且机制级全绿、空格路径已用真实代码证明产出合法 TOML；剩下的"真机 codex 接受 overlay"需要一台 Windows 按上面步骤点一遍，我已给出可直接执行的脚本和自动化方案。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

已把自动化部分做成可评审的 PR：#688

新增内容（2 个文件，diff 极小）：

• .github/workflows/ci-windows-codex.yml — 一个 windows-latest 的 CI job，在真实托管 Windows runner 上跑 codex。
• scripts/windows-codex-mcp-check.ps1 — headless 校验脚本：bili codex mcp list → 断言 codex 的 stdout 里出现 bili server。只读 config.toml、不调模型，所以不需要 E2E_UPSTREAM_* secrets。断言只看 codex stdout（bili 自己的日志走 stderr，2>$null 丢掉），避免"injecting bili MCP tools"那行造成假阳性。

本机（Linux）已做的 pre-flight：typecheck clean / build ok / launcher 测试 109/109 全绿；确认 #679 与 #683 共存正常；用假 codex 验证了 bili codex mcp list 无需上游即可启动代理并转发 mcp list、win32 下 CODEX_HOME=<overlay> env-patch 生效；tomllib 证明空格路径产出合法 TOML。

两点说明：

1. verify 步骤我故意设了 continue-on-error: true——因为我这边是 Linux agent，没法驱动真机 Windows codex 确认它在 windows-latest 上免登录能起来。它会把 transcript 传成 artifact，等你看到一次干净运行后，就能放心把它转成硬门禁。是否合入 CI 由你拍板（不合也没关系，脚本本身可单独在任何 Windows 机器上跑）。
2. 这个 PR 不关闭 E2E verify on real Windows: codex accepts CODEX_HOME overlay and registers the bili MCP server (#681 / PR #683) #686：交互式 compress 工具可见 + 并发两窗口 livePidHoldsOverlay 警告这两项验收仍需一个人在真机 Windows 上点一遍（步骤我在上一条回复里给全了）。若真机 codex 拒绝 overlay，请回填现象，我们回 [bug] Windows: codex MCP injection -c value loses its quotes through cmd.exe when node lives under a spaced path #681 讨论替代投递方式。

中文摘要：修复本身已合入且机制级全绿、空格路径已证合法 TOML；我另开了 PR #688 用一个无密钥的 windows-latest CI job 把"codex 接受 overlay 并注册 bili MCP"固化成回归，待你评审拍板，交互/并发两项真机验收仍需人工确认。

[ranxianglei]

需要真的端到端 除了现在的 还要docker 起codex的那种 之前有例子

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

收到——你要的是真·端到端（真模型往返 + 压缩），而且要 docker 起 codex 那种。我找到了你说的"之前的例子"：billion-context-dsh 的容器化 headless E2E（#128，Dockerfile + run.mjs 编排 + 容器内执行器 + npm run e2e），照它的模式给本仓库做了对应实现：

PR：#697

它把现有的 tests/e2e/e2e-codex.test.ts（真实 codex → bili 代理 → 真实 Responses 上游 → warmup/load-growth/ACP-compress/purity(/forge) 全生命周期）原封不动地塞进一个可复现 Docker 镜像里跑，而不是新写一套断言：

• scripts/e2e-docker/Dockerfile：node:22-slim + npm ci + npm run build + @openai/codex，运行时钉进镜像，宿主机不用装 node/codex
• scripts/e2e-docker/run.sh：构建镜像 → 容器内跑套件，透传 E2E_UPSTREAM_URL/KEY/MODEL/FORGE/TMO/CODEX_BIN，挂载 tmp/docker-e2e 收日志
• .dockerignore、.github/workflows/ci-e2e-docker.yml（手动触发 job，镜像 ci-e2e.yml）、npm run e2e:docker / e2e:docker:preflight

本地一条命令：

E2E_UPSTREAM_URL=http://host.docker.internal:8199/v1 E2E_UPSTREAM_KEY=... npm run e2e:docker

必须诚实说明的一点：我这个 agent 的沙箱里没有 docker，所以我没法在这里真正构建镜像 / 跑容器。我验证到的是：run.sh 语法（bash -n）干净、workflow YAML 可解析、package.json 合法且 version 未动、日志挂载路径与套件工作目录（process.cwd()/tmp，见 tests/e2e/e2e-codex.test.ts:18）对得上。镜像能否装上 codex、容器→上游网络通不通，这两点只能靠一次真实运行确认——所以 CI job 我设成 workflow_dispatch 手动触发（对其它 PR 零风险），建议你先点一次 dispatch 跑通再决定要不要转常设门禁。

和 PR #688 的关系：互补。#688 = Windows 上"MCP server 注册"这层（config 级、无密钥）；#697 = 隔离容器里的完整生命周期（真模型往返）。两者合起来把 #686 的验证面补得比较全。剩下仍需人工在真机点的是交互式 compress 工具可见性 + 并发两窗口告警那两项。

中文摘要：按你要求把真实 codex e2e 封装成可复现 docker 镜像并加了 npm run e2e:docker 与手动触发的 CI job（PR #697），沿用 billion-context-dsh #128 的容器化模式；因沙箱无 docker 无法实跑，需你点一次 dispatch 首跑确认。

[ranxianglei]

所谓真的回归,是用fake api造数据,在codex中真的发生压缩,并且验证一些列的行为是否正常.而不是仅仅跑起来.

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

明白——你要的不是"跑起来"，而是 fake api 造数据 → 压缩真的在 codex 里发生 → 断言一系列行为。这个我做出来了，并且在本地用真实 codex 跑通验证（我这个沙箱里就有 codex-cli 0.147.0，不需要 docker、不需要真模型、零 token）。

PR：#715

机制：

• tests/e2e/fake-upstream.mjs：一个确定性假上游。我对真实 codex-cli 0.147.0 逆向验证了它要的两条 wire 契约——stream:true 回 Responses SSE 助手轮；stream:false 回纯 JSON（bili 的压缩摘要调用就是解析这个）。它能识别 bili 的摘要请求（靠其精确 TASK 文本），并回一个忠实摘要：保留段里的哨兵数字、丢掉大块 filler。每个 /v1/responses 请求都落盘成 oracle 供断言。
• tests/e2e/e2e-codex-fake.test.ts（ACP_TEST_E2E_FAKE=1）：
  • overflow（window 12k）：warmup 埋哨兵，之后每轮用 resume --last 灌 ~10KB 的 bulky filler。断言的是行为而非退出码：日志出现真实 preflight compressed 事件、oracle 里摘要调用重复发生、转发出去的 payload 在持续灌入下仍保持有界（压缩把 bulk 折掉了，而不是让它累积）、哨兵活到最终转发体、且带 [Compressed conversation section] 块。
  • control（window 60k）：小轮次，断言不触发压缩、无摘要调用（排除假阳性）。

本地实测证据（真实 codex）：typecheck 干净 · build 成功 · 2/2 通过（~64s）。overflow 那轮里，连续四轮各灌 ~10KB filler，转发 payload 只涨了 ~1KB（80419→81511 字节），且每轮都有 preflight compressed —— 这就是"压缩真的在 codex 进程内折叠上下文"的直接证据，不是"能启动"而已。

用法：

npm i -g @openai/codex@latest
ACP_TEST_E2E_FAKE=1 npm run test:e2e:fake

CI：加了 ci-e2e-fake.yml（pull_request + workflow_dispatch，ubuntu-latest，装 codex，零密钥零 token），可以当每次 PR 的门禁。

一个诚实的边界：fake 编码的是 codex-cli 0.147.0 的确切 wire 格式；将来 @openai/codex@latest 若改协议，这个测试会响亮地失败（这是设计意图），届时更新 fake 即可——和现有 tests/e2e/e2e-codex.test.ts 同样的维护特性。另外，#686 里纯 Windows 专属那两项（并发窗口的 livePidHoldsOverlay 告警、交互式 compress 工具可见性）仍需真人上真机 Windows 点一下，归 #688/#683 跟踪；本 PR 覆盖的是你要的"真压缩 + 行为断言"这块。

中文摘要：按你要求做了确定性假上游 E2E（真实 codex + 进程内真压缩 + 行为断言，零 token/零密钥，可做每 PR 门禁），已在本地对真实 codex-cli 0.147.0 验证全绿（PR #715）；Windows 专属两项仍待真机人工确认。