diff --git a/tools-sync/SKILL.md b/tools-sync/SKILL.md
index 6481482..32d4835 100644
--- a/tools-sync/SKILL.md
+++ b/tools-sync/SKILL.md
@@ -241,9 +241,16 @@ commit + push 一次（junction 模型下 codex 侧自动同步，无需额外
 - **这个存储不跨 CLI 升级存活。** 2026-08-29 注册好的 7 个用户 MCP，在升级到 0.150.1
   后全部消失；2026-09-07 升到 0.153.4 后**又全没了一次**。所以每次同步都要重新审计
   Codex 侧，`~\skills_env.md` 的 MCP 配置节才是可重建的真源。
-  同一天还观察到一次**与升级无关**的消失（补齐后几分钟内 7 个条目又只剩两个自带的），
-  事后 add / remove / list 反复验证都正常、无法复现。别去猜原因——审计脚本退出码是 2
-  就直接 `-Apply` 补回来，这也是每次同步都必须跑一遍审计的理由。
+  更要命的是**消失并不需要升级**：2026-09-07/08 一次同步内复现了三次，每次都是补齐、
+  验证通过，几分钟后再查就只剩 Codex 自带的 `cua_repl` / `node_repl`。已排除 cwd 作用域、
+  Syncthing、以及 `codex mcp add/remove/list` 本身（单独测都正常，能持续数分钟）；
+  `config.toml` 经 0.153.4 复验仍然惰性——手写一节 `[mcp_servers.tomlprobe]` 后
+  `codex mcp list` 完全看不到，所以别再想靠改 TOML 绕过。add 之后在 `~\.codex`、
+  `AppData\Local\OpenAI\Codex`、`AppData\Roaming\OpenAI` 下都找不到被写过的文件，
+  怀疑该存储是账号侧下发、本地增补会被后台同步覆盖；活下来的两个恰好是 Codex 自己重新
+  播种的自带运行时。
+  **实践结论：把阶段 5 的 MCP 审计放在整次同步的最后一步**，退出码是 2 就直接 `-Apply`，
+  并在报告里写明它随时可能再没。
 
 由此还有一个已知缺口：`codex mcp add` 没有 `--tool-timeout-sec` / `env_vars` 之类的参数，
 config.toml 又不生效，所以这两个键**目前无任何设置入口**。需要它们的 MCP 记在