ACP: agent_message_chunk carries no messageId, and session_info_update floods the stream — markdown breaks in JetBrains clients

[AndriyPytel]

Symptom

In JetBrains WebStorm 2026.2 (external ACP agent acp.prime-agent), assistant markdown renders with random line breaks mid-word and mid-sentence, and markdown tables never render as tables. It gets much worse when parallel RLM subagents are running.

Evidence

Measured from the IDE's own ACP log ~/Library/Logs/JetBrains/<IDE>/acp/acp.log, one 5.7 MB session:

notification	count
SessionInfoUpdate	13,693 (only 666 unique payloads)
AgentMessageChunk	1,071
AgentThoughtChunk	416
ToolCall + ToolCallUpdate	131

• Every chunk arrives as AgentMessageChunk(content=Text(...), messageId=null).
• 530 of 1,070 consecutive AgentMessageChunk pairs have another update injected between them, almost always SessionInfoUpdate.
• 95% of SessionInfoUpdate notifications are byte-identical duplicates of the previous one, up to 30 per second. Payload is _meta["ai.primeintellect.prime-agent"].subagents[...] status/token telemetry.
• Direct stdio probe of prime-agent --mode acp shows chunk boundaries land mid-word (...ne | ensions for heavy work, ...typin | g with implicit coercion). Concatenated the text is a perfectly valid markdown table.

Analysis

ACP v1 ContentChunk already has an optional messageId: "All chunks belonging to the same message share the same messageId. A change in messageId indicates a new message has started." prime-agent leaves it null (packages/coding-agent/src/modes/acp/acp-events.ts, assistantDeltaUpdates). A client that cannot group chunks starts a new markdown block whenever any other update interleaves, so a table split across an interleave never parses. Zed hit the same class of bug from the client side and fixed it by merging chunks by messageId (zed#62631 / #62672). JetBrains has it open as LLM-25940 ("Tables are not rendered") and JUNIE-3777 ("ACP omits newlines in some agent messages").

Proposal

1. Set messageId on every agent_message_chunk and agent_thought_chunk, stable per assistant message, new id per message. Pure v1, no protocol bump, no latency cost.
2. Deduplicate and throttle session_info_update: skip payloads identical to the last one sent, and rate-limit subagent telemetry (~500 ms). 13,693 -> ~600 notifications.
3. Later, if the client negotiates ACP v2: send a final agent_message upsert with the same messageId and the full content at end of message. v2 semantics say that content replaces everything accumulated for that messageId, which gives a clean re-render of the finished markdown without waiting to stream it.

Questions

• Would maintainers take a PR for 1 and 2?
• Is there a plan to move ACP mode to protocol v2?

[snimu]

Addressed by #1781 and #1944