[BUG] cchaha无法持续性回答

[zhbdesign]

提交前确认

• 我已经阅读了 README 常见问题
• 我已经升级到最新版本后复现过这个问题
• 我已经搜索过现有 issues，确认没有重复问题
• 我已经隐藏截图和日志中的 API Key、Token、Cookie 等敏感信息

问题描述

cchaha无法持续性回答，使用同样的提示词做项目，使用cchaha和vscode内的Claudecode插件进行对比，vscode内可以一直跑，但是cchaha会进行到某个阶段就一直进行中，没任何反应，本来以为是和接口的tcp连接断开，但是看ccswitch的日志，vscode内的Claudecode插件也是一样的日志，应该不是这个问题，应该还是cchaha本身存在问题

运行环境

• 使用方式: 桌面端
• 操作系统: Windows
• 系统版本: Windows 11 23H2
• 桌面端版本: v0.3.1
• 安装来源: GitHub Release
• Bun 版本（CLI 问题填写，bun --version）:
• Node 版本（CLI 问题填写，node --version）:

Provider / 模型配置

• API 提供商: 例如 Anthropic 官方 / OpenRouter / MiniMax / Kimi / Ollama:
• Base URL:
• 使用的模型:
• 相关配置截图:

复现步骤

是否稳定复现: 是 / 否 / 不确定

错误信息与日志

在此粘贴错误信息和日志

截图或录屏

补充信息

---

@dosubot

[dosubot]

@zhbdesign 你好！这个问题与你之前提的 #553 和 #634 属于同类问题，目前已有比较明确的定位。

最关键的根因：事件循环阻塞（Sidecar 内存泄漏）

listSessions() API 每次调用都会对所有会话文件做完整的 JSONL 解析，阻塞 Bun 事件循环，导致 [1]：

• WebSocket 心跳超时
• HTTP 请求排队和连接堆积
• Sidecar 进程内存膨胀至 ~800MB 后完全冻结

这就是为什么 VSCode 的 Claude Code 插件不受影响——它没有 cc-haha 桌面端这层额外的 WebSocket 转换架构。

其他相关因素：

1. 桌面端多层消息管道 — CLI → WebSocket → UI 的架构中，流式帧可能被静默丢弃，UI 无法感知连接已断开 [2]
2. 流式空闲超时 — 系统有 90 秒的空闲超时检测，但超时后 UI 状态恢复逻辑不完善 [3]

当前修复进展：

PR #650 正在修复核心的事件循环阻塞问题，包含会话列表缓存、WebSocket handler 清理和 Sidecar 健康检查 [1]。

临时缓解方案：

在 .env 中增加超时配置：

CLAUDE_STREAM_IDLE_TIMEOUT_MS=300000
API_TIMEOUT_MS=3000000

另外建议关注 Sidecar 进程的内存占用情况，如果看到内存飙升到 800MB+，基本可以确认是这个事件循环阻塞问题。

能否补充一下你使用的 API 提供商和模型名称？不同提供商的兼容性差异较大，确认后可以给出更针对性的建议。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[zhbdesign]

[zhbdesign]

测试了几轮，发现有时候是tcp连接重置断开了，有时候没任何错误日志，就不动了

[NanmiCoder]

之前我也遇到过，但是找不到原因，而且它有时候是偶发的，这个我也之前尝试修复过，但现在看还是有这个问题。我后续先复现一下，看如何修复吧

[zhbdesign]

之前我也遇到过，但是找不到原因，而且它有时候是偶发的，这个我也之前尝试修复过，但现在看还是有这个问题。我后续先复现一下，看如何修复吧

确实是偶发性的，我那个项目，断掉以后再继续跑，后边的基本上又不断了

[zhbdesign]

之前我也遇到过，但是找不到原因，而且它有时候是偶发的，这个我也之前尝试修复过，但现在看还是有这个问题。我后续先复现一下，看如何修复吧

发现一点规律，如果是新开的会话，第一次特别容易连接重置，后边继续问答，基本上不出现了

[zhbdesign]

与ip:端口的 HTTPS 连接复用失败
复用的空闲连接在后续请求时出错，之后每 90 秒的 idle interval 只是在检查过期连接
这是典型的 连接池空闲连接被远端关闭 的问题 — 客户端复用了一个已经被服务端关闭的 keep-alive 连接。
expiration = Some(90s) 是客户端的连接池空闲超时配置（pool_idle_timeout）。

日志里的含义：

take? — 客户端从连接池取连接时，检查该连接是否已超过 90s 空闲
reuse idle connection — 连接未过期，尝试复用
但紧接着 connection error — 说明远端已经先于客户端关闭了这个连接（远端的 keep-alive 超时比 90s 短）
之后的 idle interval 每 ~90s 触发一次，是 hyper 连接池的定期清理机制，检查并移除过期的空闲连接。

问题本质：客户端的 pool_idle_timeout(90s) > 服务端的 keep-alive 超时，导致客户端复用了已被服务端关闭的连接。

修复方向：缩短客户端的 pool_idle_timeout，或在连接失败时自动重试

[zhbdesign]

客户端的 pool_idle_timeout = 90s，意思是客户端认为"空闲不超过 90s 的连接都还能用"
服务端的 keep-alive 超时 < 90s（比如可能是 30s、60s），服务端先关闭了连接
0s 请求完成，连接放回池

...

30s 服务端 keep-alive 超时，关闭了连接（客户端不知道）

...

40s 新请求来了，客户端检查：才空闲40s < 90s，连接还能用！

   → reuse idle connection → 实际连接已断 → connection error

客户端以为连接还活着（因为没到它自己设定的 90s），但服务端早就关了。客户端池里存的是一个"已死连接"。

所以要让客户端的 pool_idle_timeout 短于服务端的 keep-alive 超时，或者加连接失败自动重试。

不知道这些资料能不能帮助优化这个问题！

[zhbdesign]

[2026-05-29][13:36:24][DEBUG][cc_switch_lib::proxy::forwarder] [Forwarder] Using pooled reqwest client (preserve_exact_header_case=false, socks_proxy=false)
[2026-05-29][13:36:24][TRACE][hyper_util::client::legacy::pool] take? ("https", ***:): expiration = Some(90s)
[2026-05-29][13:36:24][DEBUG][hyper_util::client::legacy::pool] reuse idle connection for ("https", *********:)
[2026-05-29][13:36:24][DEBUG][cc_switch_lib::proxy::server] [SRV-006] connection error: connection error
[2026-05-29][13:36:41][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:38:11][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:39:41][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:41:11][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:42:41][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:44:11][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:45:41][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired
[2026-05-29][13:47:11][TRACE][hyper_util::client::legacy::pool] idle interval checking for expired