[Bug]: Grok ACP resends full cumulative terminal output in every tool_call_update, flooding ingestion for all threads #6556

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Start a Grok provider thread and have it run a long shell command that redraws a progress bar (observed with a ~21 GB model download; any high-churn terminal output should work).
2. Let the command run for several minutes, until its accumulated output exceeds ~100 KB.
3. Keep one or more unrelated threads, using any provider, active at the same time.
4. Watch ~/.t3/userdata/logs/provider/events.<grok-thread-id>.log and the responsiveness of the other threads.

Expected behavior

tool_call_update handling should be bounded. The adapter should coalesce or truncate high-frequency terminal updates, or diff them against the previous content, so that a redrawing progress bar produces at most kilobytes of runtime events per second. One busy Grok tool call should not degrade ingestion for unrelated threads.

Actual behavior

The Grok CLI emits a session/update → tool_call_update notification for every progress-bar redraw. Each notification contains the entire accumulated terminal output of the tool call, not a delta.

At a ~10/sec redraw rate with ~145 KB of accumulated output, this peaked at a sustained ~1.1 MB/s of JSON-RPC traffic, with elevated event volume from ~03:22 to ~03:56 UTC on 2026-08-13 (orchestration receipts show the flood driving ~600 ingestion dispatches/min from 03:23):

• Individual notifications reached 145,615 bytes. Stdio delivered them in 64 KB chunks, and many decode passes completed zero messages, causing even more raw/decoded protocol log churn.
• At peak the per-thread provider NDJSON log rotated a full 10 MB every ~9 seconds: nine consecutive retained rotations (~90 MB) span just 79 seconds (03:27:23–03:28:42). Earlier rotations from the storm had already been deleted; traffic then slowed (the next file spans 03:28:42–03:55:25).
• The _meta.eventId suffix reached -22430 during the session, indicating tens of thousands of notifications for one turn.

GrokAdapter canonicalizes these updates without size or rate limits. Because ProviderRuntimeIngestion and the orchestration engine process runtime events serially (see #5681), the flood creates head-of-line blocking: provider events for unrelated threads stop being projected.

In the incident that exposed this problem, ingestion stopped dispatching entirely at 03:26:17 while the storm continued. This froze live updates for every other thread and set up the permanent state loss described in #6560.

This is arguably also an upstream Grok CLI defect because tool_call_update contains cumulative content rather than a delta. The server still needs to defend against it: one provider should not be able to wedge ingestion for the entire app.

Impact

Major degradation or frequent failure

Version or commit

Desktop 0.0.33 / main @ e5c82d7

Environment

macOS 26.5.2 (Darwin 25.5.0), Grok CLI 1.0.3 (grok-4.5)

Logs or stack traces

# Raw stdio frames: 64 KB chunks, ~half of decode passes yield 0 complete messages
[2026-08-13T03:27:23.104Z] NTIVE: {..."kind":"protocol","provider":"grok","payload":{"direction":"incoming","stage":"raw","payload":{"valueType":"string","byteLength":65536}}}
[2026-08-13T03:27:23.104Z] NTIVE: {..."kind":"protocol","provider":"grok","payload":{"direction":"incoming","stage":"decoded","payload":{"valueType":"array","itemCount":0}}}

# The payload: full cumulative progress-bar output in a tool_call_update
[2026-08-13T03:27:23.108Z] NTIVE: {..."method":"session/update",...,"update":{"sessionUpdate":"tool_call_update","content":[{"type":"content","content":{"type":"text","text":"███████       ▏  15 GB/ 21 GB   61%..."}}]}}

# One retained rotation (10 MB / ~8 s of wall clock):
#   415 log lines, 166 raw frames (116 of them ~64 KB), 83 session/update notifications,
#   largest single line 145,615 bytes
# Rotation cadence during the storm:
#   log.10  03:27:23 -> 03:27:31    log.9  03:27:31 -> 03:27:40    log.8  03:27:40 -> 03:27:49 ...

Screenshots, recordings, or supporting files

No response

Workaround

Interrupt the Grok turn, or avoid progress-bar-heavy commands in Grok threads. Once the storm stops, ingestion catches up—unless the server restarts first, which triggers #6560.