[Bug] Antigravity (agy 1.1.1) 会话在自动 Context compaction 处静默卡死：turn 永不结束、取消无效、后续 prompt 全部无响应

[saileri]

[Bug] Antigravity (agy 1.1.1) 会话在自动 Context compaction 处静默卡死：turn 永不结束、取消无效，之后所有 prompt 均无响应

环境

• codeg-server 0.31.2（standalone / deb 安装，Linux x86_64，自托管 + Web UI）
• 智能体：内置 Google Antigravity，agy_acp_server 1.1.1
• 该 agent 的 env_json 配置了本地 HTTP 代理（127.0.0.1:<port>），回环地址已在 NO_PROXY
• 运行环境资源紧张：容器 4 GB RAM（cgroup 内存峰值 4034 MB，swap 已用 240 MB）
• 上游 OAuth 正常（token 在卡死前后均能自刷新），代理本身健康

现象

1. 长任务里"卡很久"是常态（见下方统计），但会概率性地演变为彻底不返回。
2. 卡死后点 UI 的「停止」：界面看起来结束了，但再发任何消息都没有反应——没有回复、没有报错、spinner 也不再变化。
3. 该会话在 codeg.db 中长期停在 in_progress。
4. 刷新页面、重启 codeg-server 都无效——因为挂住的是 agy 子进程内部的会话状态。

关键证据（一次完整卡死，日志中的标识已全部脱敏）

A. agy 日志在某一刻彻底停止增长，最后一行不完整

$CODEG_ACP_TMP_ROOT/<codeg-pid>-<rand>/agy_acp_server.par.INFO（符号链接指向带时间戳的 *.log.INFO.<date>.<pid>）停在 218602 字节、mtime 07:52:12，此后 30 秒内 size 与 mtime 均无变化。最后一行连时间戳都没写完：

I0923 07:52

（正常行形如 I0923 07:52:11.913642 <pid> local_connection.py:521] RAW WS MSG: {...}；本行只有 I0923 07:52，分钟之后即被截断）

30 秒采样：log_size 恒为 218602，进程 utime 仅 +5（几乎不耗 CPU）。

B. 最后一条下发到 codeg 的消息是一次没有终态的自动压缩

RAW WS MSG: {"stepUpdate":{"cascadeId":"<uuid>","trajectoryId":"<uuid>","stepIndex":158,
"state":"STATE_ACTIVE","source":"SOURCE_SYSTEM","target":"TARGET_USER",
"thinking":"","textDelta":"Context compaction","compaction":{}}, "seqNum":"200", ...}

此后再没有该 stepIndex 的 STATE_DONE，也没有任何新的 stepUpdate（同一步在 07:52:11.909 / .912 / .913 连发 3 次 ACTIVE 后即沉默）。

C. 会话 store 冻结，留下孤立的 ACTIVE 步

~/.gemini/antigravity-acp/conversations/<external_id>.db：

• steps 表停在 247 行（max(idx)=246），mtime 与 B 同时刻冻结；
• SELECT step_type,status,count(*) GROUP BY 1,2 出现孤立的 step_type=21, status=2（ACTIVE），其余 242 行为 status=3（DONE），另有 1 行为 status=7（早前的路径越界拒绝，与本问题无关）。

D. 不是网络或代理问题

• agy 进程存活，但只持有到 localharness_external 的本地回环 socket，该时段没有任何到 cloudcode / Google API 的出站连接（代理侧日志同步静默）；
• 同一时刻同一代理上其它流量的日志正常，代理连通用 curl --proxy 抽样验证 3 次全部 200/404（可达）；
• 无 crash、无 OOM：dmesg 无 agy/SIGSEGV/SIGILL 记录，cgroup oom_kill 0；
• acp_list_connections 仍返回该连接（web mode 下 status 一直是 connecting，本来就不可作为健康判据）。

E. 取消只结束 codeg 侧的 turn，解不开 agy 的会话锁

POST /api/acp_cancel {"connectionId":"<antigravity connection id>"} 返回 null，约 2 分钟后 journal 才出现：

[ACP] turn_complete session=Some("<uuid>") stop_reason=cancelled background_outstanding=0
[ACP] status_changed session=Some("<uuid>") Connected -> Connected

但与此同时：agy 进程没有被杀、日志不恢复、会话 store 不再增长。说明 agy 内部那次卡住的 compaction 步仍是 ACTIVE、会话锁未释放；反重力对同一 session 的 prompt 是串行的，因此后续 session/prompt 只能排队等一个永不到来的结果——这正是"按停止后再问也不动"的原因。

F. 只能靠换进程恢复

acp_disconnect → acp_connect（相同 workDir）后，codeg 正常 SIGTERM 旧 agy 并拉起新 agy（Initialize responded in 2.68s，旧进程消失），会话可继续使用。
注意：恢复会 replay 含卡死步的 trajectory——建议在此之前备份该 session db。

为什么"时不时"出现：统计

token_usage_turn 中该 agent 的全部 783 个 turn：

turn 时长	占比
< 1 min	29%
1–5 min	39%
5–10 min	15%
10–30 min	14%
> 30 min	4%

中位数 2.6 min，P90 14.5 min，最长 309 min。input_tokens > 300k 的 turn 中位耗时 11.6 min（单 turn 最高约 5.8M input / 44.7M cache_read）。

也就是说：上下文越长，越频繁触发自动压缩，越容易撞上这个静默卡死点。这不是必然复现——本机观察到的 6 次 compaction 步中，5 次后续正常推进（分别还有 1–413 个新 step），只有 1 次永久卡死，属间歇性问题。

期望

1. prompt 级看门狗：目前只有 CODEG_ACP_IDLE_TIMEOUT_SECS（默认 300，本机设为 3600）与 CODEG_ACP_SPAWN_HANDSHAKE_TIMEOUT_SECS。agent 已连接、但 prompt 永不返回且没有任何 step 进展时，codeg 没有任何发现/恢复机制。建议增加"距上次 agent 事件超过 N 分钟即判定卡死"的检测，并允许自动或一键重启该 agent 进程（保留 session 以便恢复）。
2. 取消语义明确化：当 agent 不确认取消（steering=false）时，应明确行为——要么真正终止/重启该 agent 进程，要么在 UI 上明示"取消只在客户端生效、agent 仍持锁"，避免用户以为已停止实际未停。这与 [Bug] ACP cancellation is finalized before agent confirmation, so Pi can keep running and late output is lost #364、ACP "redirect" fabricates empty ~1ms turn_completes when the agent advertises steering=false, wedging the conversation (cancelled/pending_review) and swallowing the send #590 属于同一片区域，但触发点不同（这里是 agent 端自身卡住、取消无确认）。
3. 可观测性：agent 侧完全静默（无 error 日志、无 crash、无出站连接）时，codeg 目前没有任何提示。建议在连接/会话上暴露"距上次 agent 事件 N 分钟"之类的信号，让用户能区分"在算"和"已死"。

附注

• 被截断的 I0923 07:52 表明卡死发生在日志写入过程中，怀疑是 agy 1.1.1 在 compaction 路径上的自身缺陷；如果需要，我可以提供进一步脱敏的日志片段，以及卡死步在 store 中的字段清单（steps 表 schema + 该行各列长度/状态）。

[dawNotPoi]

我来认领这个问题。初步核对发现 CodeG 当前把前端保活也计入连接活动时间，因此用户看不到 Agent 最后一次真正推进的时间；停止操作也不能保证 agy 内部那次卡住的 prompt 已释放。

我计划在 CodeG 侧做一个可验证的恢复路径：记录最后一次来自 Agent 的实际更新并在长时间静默时提示“可能仍在工作”，不按固定时长自动判死；由会话所有者显式重启这一个 ACP 连接，确认旧子进程退出后再沿原 session 恢复。先用不响应取消的假 ACP 子进程做回归测试，覆盖旧 PID 确实退出、原会话恢复、其他连接不受影响，以及保活和权限等待不会误报。再检查桌面与 Web 两条调用路径。

这次会聚焦 CodeG 的观测和恢复，不改 agy 的 compaction 实现，也不把 #364/#590 的取消语义混进来。当前内置 agy 已从报告中的 1.1.1 升级到 1.2.1，我会在实现前核对现版本行为；如果测试无法证明安全恢复，会在这里说明结果，不提交一个只有提示文字的 PR。