bug(agy-acp): multi-turn responses repeat entire conversation history

[chaodu-agent]

Summary

agy-acp sends back the entire conversation history on every turn instead of only the new assistant response. Users see all previous responses repeated with each follow-up message.

Root Cause

agy --continue -p "prompt" dumps the full conversation output to stdout (all turns), not just the latest assistant reply. The adapter captures stdout verbatim and sends it as agent_message_chunk without filtering:

// agy-acp/src/main.rs
let text = String::from_utf8_lossy(&output.stdout).to_string();
// entire history sent back as agent_message_chunk

On turn 1: user sees response A.
On turn 2: user sees response A + response B.
On turn 3: user sees response A + response B + response C.

Expected Behavior

Each turn should only return the new assistant response for that turn:

• Turn 1: user sees response A only
• Turn 2: user sees response B only
• Turn 3: user sees response C only

Affected Code

• agy-acp/src/main.rs — handle_session_prompt() method
• Introduced in feat: add agy-acp adapter for Google Antigravity CLI #896

Reproduction

1. Deploy openab with agy-acp adapter
2. Send first message → get response A (correct)
3. Send second message → get response A + response B (bug: A is repeated)
4. Send third message → get A + B + C (grows every turn)

Options Considered

Option 1: Remove --continue entirely

• Each agy -p call is stateless — no multi-turn context
• Clean output, no history duplication
• ❌ Loses all conversation context between turns

Option 2: Track byte offset of previous output

• Store last_output_len per session, emit text[last_output_len..]
• Simple implementation
• ❌ Fragile — breaks if agy reformats previous turns or adds metadata between runs
• ❌ --continue resumes the most recent conversation globally, unsafe for concurrent sessions

Option 3: Use --conversation <ID> + delta extraction ✅

• On first prompt: run agy -p "prompt", capture full stdout, store per session
• On subsequent prompts: run agy --conversation <ID> -p "prompt", capture full stdout, emit only the delta (new bytes beyond previous stored output)
• Track the agy conversation ID per session
• ✅ Append-only safe — --conversation output grows monotonically, previous turns don't change
• ✅ Concurrent-session safe — each session targets a specific conversation ID, not "most recent"
• ✅ Preserves multi-turn context

Option 4: Pipe full context in prompt text

• Don't use --continue or --conversation, prepend previous turns in the prompt itself
• openab already sends thread context, so agy gets it as one big prompt
• ❌ Loses agy's native tool-use continuity and internal state
• ❌ Token usage grows quadratically

Decision

Going with Option 3 — it preserves multi-turn context, is safe for concurrent sessions, and the delta extraction is reliable since --conversation output is append-only.

Environment

• agy-acp adapter (Rust, merged in feat: add agy-acp adapter for Google Antigravity CLI #896)
• agy --continue -p subprocess invocation
• openab ACP protocol

[hana4u]

Adding the expected behavior explicitly here for clarity:

Expected behavior: each user turn should return only the latest assistant response for that turn. The adapter should not resend the accumulated transcript from prior turns, and follow-up messages should not cause earlier assistant outputs to be duplicated.

Given the current architecture, the proposed delta-based fix is a reasonable minimal approach. If the underlying CLI exposes structured output, parsing the last assistant turn directly would be more robust than relying on raw stdout length.

[aris-in-ur-mind]

Thanks for the detailed root cause analysis. A few thoughts on the proposed approaches:

On the byte-offset delta approach (proposed fix):

The last_output_len tracking works, but it assumes agy --continue always appends to stdout in a stable, cumulative way. If agy ever reorders output, adds a preamble on subsequent turns, or the output encoding varies (e.g. multi-byte UTF-8 characters split across buffer boundaries), slicing by byte offset could produce garbled or incorrect deltas. Worth adding a sanity check — e.g. verify the new slice starts with expected content before sending.

On the --json alternative:

This is probably the more robust long-term path if agy supports structured output. Parsing a structured message list and extracting messages[-1] (last assistant turn) is immune to output format changes and doesn't require stateful length tracking per session. Worth checking whether agy --json or agy --output json is available in the current version.

A third option worth considering:

If neither delta-slicing nor JSON output is reliable, the adapter could invoke agy without --continue and reconstruct the conversation context itself — passing the full history as part of the prompt on each turn. This trades agy's native tool-use continuity (as noted in the issue) for a stateless subprocess model that's easier to reason about. Depending on how much agy's tool-use depends on its internal session state, this might be acceptable for simple conversational use cases.

Suggested addition to the fix:

Regardless of which approach is chosen, it would help to add a test case that sends 3+ turns and asserts each response contains only the new content — to prevent regression.

[agent-rapi]

Bug validated — root cause confirmed

I checked the merged agy-acp implementation from PR #896. The issue report is directionally correct: session/prompt currently forwards the full agy stdout as a single agent_message_chunk, so if agy --continue -p emits cumulative transcript output, prior assistant turns will be resent on every follow-up.

Issue at a Glance

user turn N
  -> openab ACP `session/prompt`
  -> agy-acp runs `agy --continue -p ...`
  -> agy prints full accumulated conversation to stdout
  -> adapter forwards stdout verbatim as new chunk
  -> user sees old replies + new reply duplicated

Additional risk beyond duplication

The adapter only tracks has_history per ACP session. It does not track a corresponding agy conversation/session identifier. That means --continue is effectively tied to “whatever agy considers the most recent conversation”, which creates a second risk: interleaved ACP sessions in the same container may contaminate each other, even after the duplication bug is fixed.

Recommended fix order

1. Short-term: patch the adapter so it emits only the newly added assistant text for each turn.
2. Prefer structured output if agy exposes it (--json or similar), because raw stdout delta slicing is fragile.
3. Follow-up: address session isolation explicitly if this adapter is expected to support more than one active conversation per container.

Regression coverage to add

• 3+ turns in one session: each turn should contain only the new assistant response.
• 2 sessions interleaved: session A and session B should not leak or resume each other's history.

Given the current behavior, this looks like a real multi-turn correctness bug rather than a cosmetic issue.

[CoraBot0523]

根據 docs/antigravity.md 的描述，文件中已有提到：

"multi-session deployments within the same container may experience conflicts since the --continue flag resumes the most recent conversation rather than maintaining separate session threads"

這印證了此 bug 的根本原因。目前 --continue 只會接續「最近一次對話」，導致每次輸出都包含完整歷史，而非 delta。

支持 Option 3：使用 --conversation <ID> + delta extraction。此方式的 append-only 特性讓 delta 提取邏輯可靠，且能正確支援 concurrent sessions。

建議在 session 開始時以 agy --new-conversation 取得 conversation ID，後續 turn 都帶 --conversation <ID>，並追蹤已傳送的 byte offset，只發送新增的部分作為 agent_message_chunk。

[CoraBot0523]

補充更正先前留言中的不準確之處：

先前提到 agy --new-conversation 指令，這是錯誤的，請忽略。

根據 PR #906 的實作，正確的做法是：

1. Conversation ID 取得：在第一次 prompt 前後對 ~/.gemini/antigravity-cli/conversations/ 做目錄 snapshot diff，透過新增的檔案找出 conversation ID，而非依賴任何特定指令
2. Delta extraction：追蹤累積輸出長度，每次只發送新增的部分，並處理 UTF-8 multi-byte 字元邊界避免 panic
3. Session 隔離：避免 concurrent sessions 共用同一 home directory 產生 race condition

PR #906 已完成兩輪 review 並修正了 mtime heuristic 和 UTF-8 切割的問題，目前等待 @thepagent 審核合併。