ACP dedup_wait blocks agent init for 7–26s (occasionally 60s timeout) while CLI Initialize completes in <1s

[noxenys]

TL;DR (EN): When switching/opening an agent, codeg's UI hangs on "initializing" for 7–26s (sometimes a full 60s timeout), while the underlying CLI Initialize completes in <1.1s. The wait is in codeg's ACP dedup_wait (codeg_lib::acp::manager), not the CLI. A outcome=timeout elapsed_ms=60007 case suggests dedup keeps waiting on an already-dead equivalent connection until it hits the 60s cap. Seen on v0.21.3 (Windows 11); 0.21.5 changelog doesn't touch ACP dedup.

---

现象

在 codeg 里切换 / 打开 agent 时，UI 长时间停在「正在初始化 Claude Code」。实测每次要等 7~26 秒，偶发直接卡满 60 秒才进去。

定位

查 ~/.codeg/logs 后发现：底层 CLI 的握手其实很快，慢的是 codeg 侧 ACP 的 dedup_wait（codeg_lib::acp::manager）。

CLI 的 Initialize 全都 <1.1s：

[ACP][Claude Code] Initialize responded in 746.1ms
[ACP][Claude Code] Initialize responded in 911.3ms
[ACP][Claude Code] Initialize responded in 841.7ms
[ACP][Claude Code] Initialize responded in 1.022s
[ACP][Claude Code] Initialize responded in 557.7ms

但 dedup_wait 动辄等十几到二十几秒，还有一次顶满 60s 超时：

dedup_wait ... outcome=ready   elapsed_ms=7281
dedup_wait ... outcome=ready   elapsed_ms=7734
dedup_wait ... outcome=ready   elapsed_ms=7972
dedup_wait ... outcome=ready   elapsed_ms=13259
dedup_wait ... outcome=ready   elapsed_ms=18807
dedup_wait ... outcome=ready   elapsed_ms=25976
dedup_wait ... outcome=timeout elapsed_ms=60007   timeout_ms=60000

UI 上等的「正在初始化」，实际卡的是这段 dedup 等待，不是 CLI。

两个疑问

1. 常态开销偏大：CLI 1s 内就 ready，dedup_wait 却常要等 7~26s。能否缩短，或让它以 CLI ready 为准提前返回？
2. 疑似 bug：等待失效连接直到超时。那次 outcome=timeout elapsed_ms=60007 前，日志显示同一 session 被短时间内反复 spawn。看起来 dedup 在等一个已失效 / 永不 ready 的等价连接，不会提前放弃，只能干等满 60s。建议在等待目标失效时提前失败，别顶满 timeout。

复现

同一 session 下切走再切回 agent、或短时间重复打开，较易触发长等待 / 60s 超时。

环境

• codeg 桌面版 v0.21.3，Windows 11
• Agent: Claude Code（Codex / OpenCode 同样走 ACP，现象类似）
• 注：0.21.5 的 changelog 未涉及 ACP dedup / 连接去重，估计此问题在 0.21.5 依旧；若已在更新版本修复请指正。