bug(acp): successful auto-compaction wait is reported as blocked with a misleading retry instruction

What version of Kimi Code is running?

0.39.1 (runtime reproduction); same handler confirmed in 0.41.0 and current main by source inspection

Which open platform/subscription were you using?

OpenAI-compatible API via a custom provider

Which model were you using?

qwen3.8-max; declared context window 1,000,000 tokens

What platform is your computer?

Linux x86_64, native standalone binary, kimi acp

What issue are you seeing?

During a successful automatic compaction, the ACP client receives these ordinary agent_message_chunk texts in sequence:

Compacting conversation context…
Compaction is blocked by the current turn; retry when the turn is idle.
Compaction completed.
[compaction summary]
[the original turn continues and answers successfully]

The middle message tells the user that compaction cannot proceed and asks them to retry, although the engine is already compacting and the turn is simply waiting for it. The misleading text is also retained as assistant text by clients that persist agent_message_chunk.

This was reproduced on 0.39.1 with sequential prompts: no manual /compact, no concurrent session/prompt, and no retry action. Native full_compaction.complete and successful continuation were both observed.

What steps can reproduce the bug?

1. Start kimi acp from an ACP client, initialize it, and create a session using a configured model/provider.
2. Build a long conversation with synthetic filler sent in successive normal session/prompt requests; wait for each request to finish before sending the next.
3. Continue until automatic compaction starts and the next model step waits at the blocking threshold. The exact input size depends on tokenization and context-window configuration.
4. Inspect session/update notifications whose update.sessionUpdate is agent_message_chunk. Observe the start -> misleading blocked/retry text -> completed -> normal answer sequence above.

A small regression fixture can drive the same ACP subscription with compaction.started(trigger=auto), compaction.blocked(turnId=...), and compaction.completed. The existing engine test blocks the turn until auto compaction finishes already demonstrates that the blocked event belongs to a successful wait path, before full_compaction.complete and turn.step.started:
https://github.com/MoonshotAI/kimi-code/blob/5efca0c3116743855c28426000073bfe34a4862f/packages/agent-core-v2/test/agent/fullCompaction/fullCompaction.test.ts#L1662-L1704

What is the expected behavior?

Describe the actual state, for example: "Waiting for context compaction to finish; the turn will continue automatically." Alternatively, keep only the existing compacting progress message.

Do not ask the user to retry when the turn is already waiting for an active compaction. Genuine cancellation, failure, and a rejected manual request should retain their separate meanings. Add an ACP regression test for the successful start -> blocked/wait -> completed sequence.

Additional information

Root cause:

1. FullCompactionService.block() requires an existing active compaction, emits CompactionBlocked, then awaits active.promise. The turn is blocked on compaction, not the other way around.
2. AcpSession.init() translates every compaction.blocked into the reversed sentence above. emitLocalChunk() sends it as plain assistant text.

Latest stable 0.41.0 (npm latest as checked on 2026-09-08) still contains both sides of this logic:

• Wait implementation: https://github.com/MoonshotAI/kimi-code/blob/95478e8c7ba248fd2470d5bb151555ec7fedd19d/packages/agent-core-v2/src/agent/fullCompaction/fullCompactionService.ts#L547-L560
• ACP wording: https://github.com/MoonshotAI/kimi-code/blob/95478e8c7ba248fd2470d5bb151555ec7fedd19d/packages/acp-server/src/session.ts#L325-L329

Current main f12d59e089e2531a33fbca30b26ffeabd5862b45 also retains the sentence. Version 0.41.0 and main were source-checked; they were not claimed as new live E2E reproductions. The 0.39.1 installed binary was inspected, and a local replay of its corresponding unmodified block/subscription methods reproduced the misleading message while the waiting promise subsequently resolved successfully.

Only generic reproduction details and public source references are included; no private session logs or credentials are attached.

Contribution

• I am willing to submit a PR for this bug fix myself (please wait for maintainer approval in this issue first)

Start in packages/acp-server/src/session.ts around the compaction.blocked handling and compare it with packages/agent-core-v2/src/agent/fullCompaction/fullCompactionService.ts. Read the existing full-compaction test at packages/agent-core-v2/test/agent/fullCompaction/fullCompaction.test.ts, then add an ACP regression test for the auto-compaction start, blocked/wait, and completed sequence. Done means the client receives non-misleading progress text and genuine cancellation, failure, and rejected manual requests retain their meanings.