From 7df88445c57fd6a540bf86d5ecd69522bfc1c514 Mon Sep 17 00:00:00 2001 From: Myfro9 <36755290+Myfro9@users.noreply.github.com> Date: Wed, 23 Sep 2026 17:49:46 +0800 Subject: [PATCH] =?UTF-8?q?tools-sync:=20Codex=20MCP=20=E5=9B=9E=E9=80=80?= =?UTF-8?q?=E7=9A=84=E5=AE=9A=E9=87=8F=E5=AE=9E=E6=B5=8B=E2=80=94=E2=80=94?= =?UTF-8?q?=E7=AA=97=E5=8F=A3=20<25s=EF=BC=8C=E4=B8=94=E6=98=AF=E5=9B=9E?= =?UTF-8?q?=E9=80=80=E5=88=B0=E9=99=88=E6=97=A7=E5=BF=AB=E7=85=A7=E8=80=8C?= =?UTF-8?q?=E9=9D=9E=E6=B8=85=E7=A9=BA?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/tools-sync/SKILL.md b/tools-sync/SKILL.md index 32d4835..24987e6 100644 --- a/tools-sync/SKILL.md +++ b/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 记在