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

快速结论：该报错发生在 Open Interpreter 0.0.38 的 /model 选择器中，当已登录（authenticated）的 Provider 触发模型列表加载时，界面会永远停留在 “Loading models…” 状态。优先排查：将 Open Interpreter 回退到 0.0.34 版本，或升级到包含 #1878 修复的后续版本。

适用环境：Open Interpreter 0.0.38（独立二进制，x86_64-unknown-linux-musl，内部 client_version 0.147.0）；Debian 13 (trixie)，x86_64；已通过 OAuth 凭据文件或环境变量（如 KIMI_API_KEY、ANTHROPIC_API_KEY）完成 Provider 认证。

最快修复方案：暂无确认的一步修复方案（Issue 中确认的修复在 #1878 中合并，需等待下一个版本发布）。可优先尝试：将二进制回退到 0.0.34 版本，使用相同的 CODEX_HOME、配置和凭据即可正常显示模型列表。

注意事项：该问题仅影响已认证 Provider 的模型列表加载路径；未认证 Provider（显示设备登录界面）不受影响。清除模型缓存、手动 curl 验证网络/凭据均不能解决此问题。

问题场景

在 Open Interpreter 0.0.38 中，用户对任意已认证 Provider（如 kimi-for-coding、Anthropic）执行 /model 命令，在选中 Provider 后，界面卡在 “Select Model for Provider / Loading available models… / Loading models…”，等待 60 秒以上仍无响应。回退到 0.0.34 同一配置下可立即加载完整模型列表，确认为 0.0.38 回归。

报错原文

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

Select Model for <Provider> / Loading available models… / Loading models…

原因分析

可能原因：0.0.38 版本在 interpreter/model/list 路径中存在回归——当请求已认证 Provider 的模型列表时，代码在“应用缓存”或“读取存储认证信息”的某个 await 点上发生内部死锁，HTTP 客户端从未发起实际网络请求。日志证据显示请求到达模型管理器、应用缓存后即静默，/proc 检查确认没有新的 socket 和文件描述符，所有 tokio 线程均 parked 在 futex/epoll_wait，与网络阻塞无关。可能原因是 #1878 中修复的“认证解析与模型列表刷新之间的异步等待顺序”问题。

环境排查

确认 Open Interpreter 版本为 0.0.38（内部 client_version 报 0.147.0），可对比 0.0.34 二进制。
确认 Provider 已认证（存在 OAuth 凭据文件如 ~/.openinterpreter/credentials/kimi-code.json，或已设置 Provider 环境变量）。
检查 ~/.openinterpreter/logs_2.sqlite 中 logs 表，确认请求日志是否止步于 models cache: cache entry applied 或 models cache: no usable cache entry。
确认未认证 Provider 路径正常（会显示设备登录界面），以排除通用 UI/事件循环问题。
可通过 interpreter debug models 确认目录渲染正常（该路径不同，不受影响）。

解决步骤

回退版本（首选，已验证）：将 Open Interpreter 二进制从 0.0.38 回退到 0.0.34，保持相同的 CODEX_HOME、配置和凭据，/model 应能立即显示完整模型列表。
检查修复版本：确认当前使用的版本是否已包含 #1878 的修复（合并到 main，将在下一版本发布）。若可用，升级到修复后的版本。
确认非缓存/网络问题（排查用，不能修复）：可尝试手动 curl Provider 的 /models 端点（使用相同 bearer token）确认返回 200；也可尝试清除缓存文件后重现，但 Issue 证据表明缓存命中与否均会卡住。
等待修复发布：由于 0.0.38 本身无已验证的配置级修复，在修复版本发布前，回退 0.0.34 是最可靠的规避方式。