/model picker hangs forever at “Loading models…” for authenticated providers (0.0.38; works in 0.0.34)

快速结论：该问题出现在 Open Interpreter 0.0.38 中，只要所选 provider 已认证，/model 选择器就会卡在 “Loading models…” 无限等待；应优先回退到 0.0.34，或确认是否已升级到包含 #1878 修复的版本。

适用环境：Open Interpreter 0.0.38（standalone, x86_64-unknown-linux-musl，内部 client_version 为 0.147.0），Debian 13（trixie）x86_64；评论中另在 0.0.40（aarch64-apple-darwin）复现。已认证 provider 包括 kimi-for-coding（OAuth credential / KIMI_API_KEY）、Anthropic（ANTHROPIC_API_KEY）、ChatGPT（auth.json，auth_mode: "chatgpt"）与 OpenRouter（OPENROUTER_API_KEY）。

最快修复方案：Issue 中明确验证过的可用方案是回退到 0.0.34：将 current 指向 0.0.34 发布目录（例如 ln -sfn releases/0.0.34-… current），并在 version.json 中设置 "dismissed_version": "0.0.40"。0.0.34 在认证模型解析路径中没有该死锁。

注意事项：评论指出 #1878 的修复随 0.0.40 发布后只能“掩盖”问题：缓存新鲜（TTL = 300 秒）时 /model 可用，缓存过期后会回落到仍会挂起的认证 list_models(OnlineIfUncached, …) 路径，再次死锁。因此 0.0.40 并不能作为完整修复，根因仍然存在；在官方给出正式修复前，回退版本仍是相对可靠的规避手段。

问题场景

在 Open Interpreter 0.0.38 中启动 interpreter，执行 /model 命令并选择 provider 后，界面进入 “Select Model for <Provider>” 页面，显示 “Loading available models…” / “Loading models…”，spinner 永不结束（已等待 60 秒以上）。该问题只在所选 provider 已认证时出现；未认证 provider 会正常进入 device-login 页面，因此主要影响已登录用户。

同一份 CODEX_HOME、配置和凭据在捆绑的 0.0.34 二进制下可以瞬间渲染完整模型列表，因此更接近于 0.0.38 在认证 interpreter/model/list 路径上的回归。评论确认该问题并不仅限于 0.0.38：0.0.40 在缓存过期后同样复现。

报错原文

/model picker hangs forever at "Loading models..." for authenticated providers (0.0.38; works in 0.0.34)

INFO  codex_models_manager::manager | list_models{refresh_strategy=online_if_uncached}: models cache: evaluating cache eligibility client_version="0.147.0"
INFO  codex_models_manager::cache   | models cache: loaded cache file ... cached_version=Some("0.147.0")
INFO  codex_models_manager::cache   | models cache: cache hit ... cache_ttl_secs=300
INFO  codex_models_manager::manager | models cache: cache entry applied models_count=8 etag=None
<nothing further for this request — spinner hangs forever>

原因分析

根据 Issue 证据，最可能的原因是 0.0.38 在认证 interpreter/model/list 路径中存在内部死锁：请求已进入 models manager 并应用缓存，但之后没有任何响应或 HTTP 客户端活动。对挂起进程的 /proc 检查显示 tokio 运行时线程全部 parked 在 futex/epoll_wait，按 Enter 后没有打开任何 socket、没有新 fd、没有子进程，这与网络阻塞不符，更像是等待某个永不完成的内部 await。

该问题与网络、认证健康、缓存、UI 事件循环、interpreter debug models 路径以及 stale state/权限均无关（均被逐一排除）。评论补充说明，0.0.40 中 #1878 的修复仅让已认证 provider 优先使用可用且新鲜的缓存，从而在 TTL（300 秒）内绕过问题；一旦缓存过期，list_models_from_cache_if_present 快路径返回 None，后续认证 list_models 调用仍会像修复前一样死锁。

环境排查

确认 Open Interpreter 版本：0.0.38 或 0.0.40；0.0.34 无此问题。
确认平台：0.0.38 为 Debian 13（trixie）x86_64，standalone x86_64-unknown-linux-musl，内部 client_version 为 0.147.0；0.0.40 复现环境为 aarch64-apple-darwin。
确认所选 provider 是否已认证：OAuth credential 文件（如 ~/.openinterpreter/credentials/kimi-code.json）、provider 环境变量（KIMI_API_KEY、ANTHROPIC_API_KEY、OPENROUTER_API_KEY）或 ChatGPT auth.json（auth_mode: "chatgpt"）。
检查模型缓存状态与 TTL：缓存命中时 0.0.40 可临时恢复，缓存过期（cache_ttl_secs=300）后再次挂起。
检查日志：~/.openinterpreter/logs_2.sqlite 的 logs 表，观察是否出现 models cache: cache entry applied 之后无后续 codex_http_client::client “Request completed” 行。

解决步骤

若当前为 0.0.38，回退到 0.0.34：在安装目录中执行 ln -sfn releases/0.0.34-… current（具体发布目录名以实际安装为准）。
如果使用自动更新提示，在 version.json 中加入 "dismissed_version": "0.0.40" 以避免被升级到仍存在该问题的 0.0.40。
若已在 0.0.40 且希望临时缓解，可在缓存新鲜期内打开 /model 并选择 provider；但超过 300 秒 TTL 后需重新预填充缓存，且该方法并未修复根因，仅为规避。
排查时确认所选 provider 为已认证状态，并在缓存命中/未命中两种路径下分别测试，以确认是否落入认证 list_models(OnlineIfUncached, …) 的死锁路径。
等待官方在后续版本发布针对认证模型刷新路径死锁的正式修复；#1878 的缓存优先改动不构成完整修复。

验证方法

回退到 0.0.34 后，在同一 HOME（相同配置、凭据与缓存）下启动 interpreter，执行 /model 并选择已认证 provider，应能立即渲染完整模型列表（如 k2p5、k2p6、k2p7 (current)、k3 (default) 等）。若使用 0.0.40，需额外等待超过 300 秒缓存 TTL 再测试一次，以确认是否仍会在缓存过期后挂起。