[BUG] 关于会话卡住不动的两点分析

[zhbdesign]

提交前确认

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

问题描述

关于每次新会话第一次提问卡住的分析:
1.请求大模型没有异常，大模型返回"stop_reason":"end_turn"，但是任务还没有结束，后边确实还有很多东西要执行，因为ui上也一直显示运行中，在等待
2.cc-haha取消了连接，导致ui也一直显示执行中，但是这个没找到方法去验证cc-haha的相关错误原因，都是用的代理mitmproxy去拦截打印的，但是流程比较长，cc-haha调用ccswitch，ccswitch调用mitmproxy，mitmproxy调用大模型
相关issue:
#634
#687
#696

运行环境

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

Provider / 模型配置

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

复现步骤

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

错误信息与日志

在此粘贴错误信息和日志

截图或录屏

补充信息

---

@dosubot

[dosubot]

@zhbdesign 你好！你分析的两个场景和你之前在 #687 报告的问题一脉相承，而且你这次通过代理抓包提供的数据非常有价值。

关于你的两点分析：

场景 1：大模型返回 "stop_reason":"end_turn" 但 UI 一直显示运行中

从你抓到的数据看，最后一次请求的 stop_reason 是 "end_turn"，但倒数第二次是 "tool_use"。问题很可能出在 桌面端多层消息管道（CLI → WebSocket → UI）中，message_stop 事件在经过 WebSocket 翻译层时被静默丢弃，导致 UI 没有收到 message_complete 信号来完成状态转换 [1] [2]。代码中虽然有防御性的自动补发 end_turn 机制 [3]，但桌面端 sidecar 进程的事件循环阻塞（listSessions() 同步解析所有 JSONL 文件）会导致 WebSocket 心跳超时和帧丢失 [4]。

场景 2：cc-haha 取消了连接

这是你之前定位的 HTTP 连接池空闲超时不匹配问题——客户端 pool_idle_timeout=90s 大于服务端 keep-alive 超时，导致复用已被远端关闭的连接。新会话第一次提问特别容易触发，因为连接池里的空闲连接最可能已经是"死连接" [1]。

当前修复状态：

• #732 中 @NanmiCoder 表示会在下个版本优化 [2]
• PR #650 包含事件循环阻塞、内存泄漏和 sidecar 健康检查的修复，但尚未合并 [4]

临时缓解建议：

1. 在 .env 中增加超时配置：

   CLAUDE_STREAM_IDLE_TIMEOUT_MS=300000
   API_TIMEOUT_MS=3000000

2. 长时间任务建议暂时使用 CLI 端（更稳定，因为绕过了 WebSocket 和 sidecar 会话管理层）

3. 监控任务管理器中 sidecar 进程内存，超过 800MB 则重启桌面端

你之前提到使用 ccswitch 时出现 connect error 但不用 ccswitch 就没问题的观察——这可能与 cc-haha 桌面端和 CLI 端读取配置路径不同（桌面端用自己的 settings.json，ccswitch 用 ~/.claude/settings.json）有关，导致连接参数存在差异。这个方向值得继续排查。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[NanmiCoder]

你现在这个链路感觉太长了，我建议针对同样的开发任务和同样的提示词，直接连接模型厂商去测试。

因为我这边在 v0.4.0 版本中，已经没有再出现过这种情况了

[zhbdesign]

你现在这个链路感觉太长了，我建议针对同样的开发任务和同样的提示词，直接连接模型厂商去测试。

因为我这边在 v0.4.0 版本中，已经没有再出现过这种情况了

因为我直接连接大模型也是必现，但是找不到直接看请求的办法，才搞的这个链路，如果你那边没问题，是不是和模型有关，用的是商汤的deepseek-4-flash，速度不慢

[zhbdesign]

你现在这个链路感觉太长了，我建议针对同样的开发任务和同样的提示词，直接连接模型厂商去测试。

因为我这边在 v0.4.0 版本中，已经没有再出现过这种情况了

我重新安装，用cc-haha自己的provider，测试6遍，已经没问题，那就是ccswitch自身连接断开，不返回数据，cc-haha就一直执行中

[zhbdesign]

我在ccswitch找了相关issue，这个异常并不是连接异常，ccswitch转换数据也会出现这个异常

[zhbdesign]

这个基本上确定就是大模型和ccswitch之间的问题，目前卡住没问题了