Summary
When kimi-code is driven as an ACP agent (kimi acp), turns that the agent starts on its own — e.g. resuming after a background subagent / background bash task completes, or a cron/scheduled reminder fires — never emit any session/update notifications. The client only receives traffic for these turns once the user sends a new prompt, and even then the missed content is lost (not buffered). From the client's perspective the agent goes silently idle, does invisible work, and the results never appear.
Environment
- kimi-code 0.29.0 (
~/.kimi-code/bin/kimi), macOS
- ACP client: a desktop app hosting
kimi acp over stdio (SergeCode, a T3-Code-style host)
Reproduction
- Over ACP, start a session and ask the agent to delegate work to background subagents (the
Agent tool with run_in_background, or background Bash tasks).
- Wait for the background tasks to complete. The kimi runtime injects the completion notification into the session and the agent autonomously starts a new turn (reads the task output, posts a summary) — with no
session/prompt from the client.
- Observe the ACP wire during that window.
Expected: the agent-initiated turn streams session/update notifications as it happens — user_message_chunk for the injected completion notification, then agent_thought_chunk / agent_message_chunk / tool_call* for the turn's work. ACP permits agent→client notifications outside the prompt lifecycle.
Actual: zero session/update notifications while no prompt is in flight. The only agent→client traffic is session/request_permission for tool calls made by those autonomous turns — which proves the turns execute but their content is suppressed. The turns' text/tool activity is also not flushed when the next session/prompt arrives; it is never emitted at all.
Evidence (production ACP session log)
A real session where 3 background subagents + 2 background validation commands completed while the client was idle (5 autonomous turns between 18:24–18:31):
| window |
session/update from autonomous turns |
other agent→client traffic |
| 18:24–18:28 (3 subagent-completion turns) |
0 |
12 × session/request_permission (Read/Bash approvals matching those turns' tool usage) |
| 18:30–18:31 (2 task-completion turns) |
0 |
— |
- Client-initiated prompt turns in the same session stream normally (thousands of
session/update including agent_message_chunk).
- The 5 autonomous replies' text appears nowhere in the wire log — including during/after the next client prompt — so the content is dropped, not buffered.
Why this matters
Any ACP client (Zed, JetBrains, custom hosts) that runs the agent with background tasks, subagents, or cron reminders will permanently miss entire turns: the user sees the agent go quiet, and the work it did autonomously is invisible in the client UI.
Suggested fix
- While no
session/prompt is in flight, emit session/update for agent-initiated turns exactly as for prompt-driven turns (including a user_message_chunk for the injected trigger notification).
- Since ACP has no explicit turn-start notification, consider a
_meta marker on updates belonging to agent-initiated turns (e.g. _meta: { "agentInitiated": true }) so clients can bracket them into a synthesized turn for UI purposes — right now a client cannot tell where an unprompted turn begins/ends except by quiescence.
Related: #1485 (zero agent_message_chunk within a prompt), #1956 (session history on load) — this one is specifically about live agent-initiated turns never being streamed.
Summary
When kimi-code is driven as an ACP agent (
kimi acp), turns that the agent starts on its own — e.g. resuming after a background subagent / background bash task completes, or a cron/scheduled reminder fires — never emit anysession/updatenotifications. The client only receives traffic for these turns once the user sends a new prompt, and even then the missed content is lost (not buffered). From the client's perspective the agent goes silently idle, does invisible work, and the results never appear.Environment
~/.kimi-code/bin/kimi), macOSkimi acpover stdio (SergeCode, a T3-Code-style host)Reproduction
Agenttool withrun_in_background, or background Bash tasks).session/promptfrom the client.Expected: the agent-initiated turn streams
session/updatenotifications as it happens —user_message_chunkfor the injected completion notification, thenagent_thought_chunk/agent_message_chunk/tool_call*for the turn's work. ACP permits agent→client notifications outside the prompt lifecycle.Actual: zero
session/updatenotifications while no prompt is in flight. The only agent→client traffic issession/request_permissionfor tool calls made by those autonomous turns — which proves the turns execute but their content is suppressed. The turns' text/tool activity is also not flushed when the nextsession/promptarrives; it is never emitted at all.Evidence (production ACP session log)
A real session where 3 background subagents + 2 background validation commands completed while the client was idle (5 autonomous turns between 18:24–18:31):
session/updatefrom autonomous turnssession/request_permission(Read/Bash approvals matching those turns' tool usage)session/updateincludingagent_message_chunk).Why this matters
Any ACP client (Zed, JetBrains, custom hosts) that runs the agent with background tasks, subagents, or cron reminders will permanently miss entire turns: the user sees the agent go quiet, and the work it did autonomously is invisible in the client UI.
Suggested fix
session/promptis in flight, emitsession/updatefor agent-initiated turns exactly as for prompt-driven turns (including auser_message_chunkfor the injected trigger notification)._metamarker on updates belonging to agent-initiated turns (e.g._meta: { "agentInitiated": true }) so clients can bracket them into a synthesized turn for UI purposes — right now a client cannot tell where an unprompted turn begins/ends except by quiescence.Related: #1485 (zero
agent_message_chunkwithin a prompt), #1956 (session history on load) — this one is specifically about live agent-initiated turns never being streamed.