## 现象 在插件配置页把「思考档位配置(3.14+)」开关拨为**关**并保存后,ZCode 从此"退不掉":每次完全退出,看护进程都会执行一次还原、然后**自动重启 ZCode**。且还原是白干的——下次启动后档位配置又回来了,sync 再次检测到"开关=关 vs 实际=已配置",再挂新看护。无限循环。 期间看护进程每个会话启动都会多挂一个(实测堆积过 10 个),全部带着同一份永远完不成的指令。 ## 复现步骤 1. 设置 → 插件 → zcode-tokenspeed → 配置,「思考档位配置(3.14+)」拨为关,保存 2. 完全退出 ZCode(macOS Cmd+Q) 3. 观察:ZCode 被自动重启;`_apply_after_exit.log` 出现 `处理完成(失败 0 项),重启 ZCode / DONE` 4. 重启后新会话的 sync 又记录 `已启动退出后看护: --want=reasoning_config=off` 5. 回到第 2 步,永远循环 ## 根因 `--reasoning-config --revert` 的目标是 `provider_config.json`——**这是客户端自己的权威配置文件,启动时会用内存中的数据整份重写**。于是: ``` 退出 → 看护还原(成功)→ 重启 ZCode → 客户端把档位规则写回 provider_config.json → sync 发现 want=off 但实际=on → 挂新看护 → 下次退出再还原 → 死循环 ``` 实测时间线(macOS,插件 0.6.6,ZCode 3.14.3): - `16:14:49` 看护执行还原,`执行汇总(模式:还原)√ 3.14+ 原生档位配置 合计 1 项:成功 1`,随后重启 ZCode - 客户端启动后,`zcode_patcher.py --reasoning-config --check` 重新显示 `已是最新 6 个`(规则被客户端写回) - `16:15:09/10/14` 三个新会话各挂一个新看护,want 仍是 `reasoning_config=off` 对比:其余开关(如 model_width / thought_slider)的还原目标是 app.asar,客户端不会重写,还原能真正生效、循环会终止。**只有 reasoning_config 的还原目标是客户端会自己重写的文件**,注定无效。 ## 修法建议(任选其一) 1. **改语义(推荐)**:开关从"开/关"改为"托管/不托管"——关=不再写入配置,但不主动还原客户端已有的规则(对客户端自己的文件,还原没有意义) 2. **熔断**:`check_state` 识别"上轮已还原但实际仍为已配置"的状态,连续 N 轮后放弃并日志提示"该开关与客户端行为冲突,无法保持关闭" 3. 至少在配置页开关描述里注明:关闭此项会导致每次退出后自动重启(把行为说清楚) ## 相关 - PR #4(macOS 平台兼容修复)让看护链路在 macOS 上真正可运行后,这个问题在 macOS 上才暴露出来——但机制本身与平台无关,Windows 同样存在。 环境:macOS arm64(darwin 25.6.0)、ZCode 3.14.3、插件 0.6.6、Python 3.11.8
Activity
fix: 思考档位关闭改为不托管语义,根治退出无限重启死循环 (Issue #5, 0.6.16)