tools-sync: Codex MCP 回退的定量实测——窗口 <25s，且是回退到陈旧快照而非清空

2026-09-23 在 win-hp-bowei 上改完 stm32cubemx 解释器并补上 mcp_dsa815，T+0 验证
通过，T+25s 再查就已经退回去了，T+50/75s 保持。codex-cli 0.150.1 全程未升级。

两点修正旧记载：
- 窗口不是'几分钟'，是 25 秒以内；
- 不是'清空到只剩 cua_repl/node_repl'。13 个条目里 altium/kicad/matlab 等全在，
  只有本次增改被抹掉，stm32cubemx 精确退回修改前那一版。说明覆盖它的是一份
  有内容的远端快照，不是清零。

实践结论随之修正：这类机器上 Codex 侧 MCP 改动是徒劳的，-Apply 之后必须在 25s
后复验，没活下来就如实写'未能持久、该机仍在用旧配置'，不要在报告里记成已修复。

tools-sync/SKILL.md

@@ -249,8 +249,26 @@ commit + push 一次（junction 模型下 codex 侧自动同步，无需额外
   `AppData\Local\OpenAI\Codex`、`AppData\Roaming\OpenAI` 下都找不到被写过的文件，
   怀疑该存储是账号侧下发、本地增补会被后台同步覆盖；活下来的两个恰好是 Codex 自己重新
   播种的自带运行时。
-  **实践结论：把阶段 5 的 MCP 审计放在整次同步的最后一步**，退出码是 2 就直接 `-Apply`，
+  **2026-09-23 实测定量（win-hp-bowei，codex-cli 0.150.1，全程未升级）**：回退窗口
-  并在报告里写明它随时可能再没。
+  **小于 25 秒**，不是此前记的"几分钟"。做法是改完立即验证，再按 25 s 间隔轮询：
+
+  | 时刻 | 条目数 | 本次新增的 mcp_dsa815 | 本次改过的 stm32cubemx |
+  |---|---|---|---|
+  | T+0   | 14 | 在 | `C:\Python314\python.exe`（已修） |
+  | T+25s | 13 | **没了** | **退回 `.venv\Scripts\python.exe`（坏的）** |
+  | T+50s | 13 | 没了 | `.venv`（同上） |
+  | T+75s | 13 | 没了 | `.venv`（同上） |
+
+  而且**它不是"清空到只剩自带运行时"，是"回退到一份陈旧的账号侧快照"**：13 个条目里
+  altium / kicad / matlab / simetrix / mcp_n9320b 等全都还在，只有本次的增改被抹掉，
+  且 stm32cubemx 精确地退回到修改之前那一版配置。这比"被清空"更能说明问题——本地
+  `codex mcp add` 的写入会被一份**有内容的**远端快照覆盖，而不是被清零。
+
+  **由此修正实践结论**：在出现这种回退的机器上，**Codex 侧的 MCP 改动是徒劳的**，
+  每轮同步重新 `-Apply` 只会在报告里留下一行假的"已修复"。正确做法是：照常 `-Apply`
+  （成本低，万一这台机器没这毛病就生效了），**但必须在 25 s 后复验**，没活下来就在
+  报告里写明"Codex 侧改动未能持久，该机 Codex 实际仍在用 <旧配置>"，不要写成已修复。
+  真正的修复要从账号侧那份快照入手（目前无已知入口）。
 
 由此还有一个已知缺口：`codex mcp add` 没有 `--tool-timeout-sec` / `env_vars` 之类的参数，
 config.toml 又不生效，所以这两个键**目前无任何设置入口**。需要它们的 MCP 记在