[Bug] [0.8.0][WSL2] Single RLM child can make daemon worker unresponsive due to unthrottled rlm_child_update streaming

[theyv]

Summary

On Prime Agent 0.8.0, a single long-running RLM child can make its parent session worker unresponsive. This is not caused by spawning many subagents.

Environment

• Prime Agent 0.8.0
• Node.js 22.23.2
• WSL2 2.7.11.0
• Linux kernel 6.18.33.2-microsoft-standard-WSL2
• Daemon sockets and ~/.prime stored on ext4, not DrvFS

Reproduction

1. Start Prime Agent in daemon mode.
2. Spawn exactly one RLM child.
3. Give it a long, tool-heavy or long-streaming task.
4. Keep the parent session open for 10–20 minutes.

Actual behavior

The daemon eventually reports errors such as:

Timed out waiting for daemon worker response to attach
Timed out waiting for daemon worker response to worker_sync_agent_peers
Timed out waiting for daemon worker response to heartbeats_list
Timed out waiting for daemon worker hello
Daemon reconnection failed: Unknown active session

The worker process can still be alive, listening on its Unix socket, and using about 650 MiB RSS. No V8 OOM or fatal error was present.

Before one failure, the parent had only eight child_usage_attributed entries. This rules out excessive child count or usage-attribution volume as the main trigger.

Likely cause

In packages/coding-agent/src/core/agent-session.ts, every child assistant message_update performs:

const text = compactRlmText(readAssistantText(event.message as AssistantMessage));
emitChildUpdate();

emitChildUpdate() also calls:

childSession?._contextTokensForCurrentMessages()

Therefore, every provider streaming delta triggers text reconstruction, context-token calculation, and an rlm_child_update daemon event. As the child context grows, one streaming child can overload the worker and daemon event path.

Current upstream main still contains this behavior.

Local workaround tested

Coalesce only streaming message_update events to at most one update per second:

let lastStreamingChildUpdateAt = 0;

// ...

const now = Date.now();
if (event.type === "message_update" && now - lastStreamingChildUpdateAt < 1_000) return;
lastStreamingChildUpdateAt = now;

Important lifecycle events remain immediate:

• message_start
• message_end
• tool start/end
• agent end
• errors and terminal child status

Validation

With this patch:

• full monorepo build passed;
• 392/392 relevant RLM and daemon tests passed;
• a regression test with 1,000 rapid child stream deltas passed;
• live attach remained responsive while a child was running;
• no Unknown active session, worker timeout, or replacement supervisor occurred during the controlled run;
• a separate real implementer child remained active for over 20 minutes.

Expected fix

Please throttle or coalesce child streaming UI updates upstream. Ideally, avoid recalculating full context tokens and assistant text for every provider delta while preserving immediate terminal updates.

Related: #1054.

[breedx]

+1 — reproduced on Linux, so this is not WSL2-specific.

Prime Agent 0.7.4 (a soft fork, with no changes in this path), Ubuntu 24.04, Node
v25.9.0, 4 vCPU, ext4, default sockets. Same failure mode as reported, including
the heartbeats_list timeout.

What I think this thread is missing is a number for how far the worker misses
the handshake. The worker is not unresponsive — it is slow. I probed its own unix
socket directly, three times in a row:

try1: connect 0ms  hello 3827ms
try2: connect 0ms  hello 4045ms
try3: connect 0ms  hello 4616ms

It answers with a valid daemon_hello every time, at ~3.8-4.6s. Against
adoptOrRecoverWorker's connectWorker(worker, 2000) and recoverWorker's
connectWorker(worker, 1500), it misses both budgets by 2-3x deterministically.
That is why it re-poisons after every supervisor restart rather than
intermittently.

The starvation looks like exactly the cause described here. Sustained 215-243%
CPU across 4 cores, 13 threads, 2170MB RSS, and the session tail is dominated by
child streaming:

295 of the last 400 events = child_usage_attributed
7 sub-agents, 3 still actively streaming

Agreeing with the point that child count is not the driver: 8 of my 9 workers
sit at 115-142MB and adopt without trouble. Only the one with live streaming
children is affected, and it is the only one that ever enters failed.

Two things that may be useful for triage:

1. retry_worker does not recover this. #1641 reports recovering 16/16
workers via the internal retry path, so I tried it here — sent
{"type":"retry_worker","activeSessionId":"..."} over a protocol-7 envelope to
the supervisor socket:

after 12.5s: {"success":false,"error":"Waiting for a client with fresh runtime context"}

That is consistent rather than contradictory: retry repairs a descriptor whose
worker is merely unadopted, but it runs the same 1500ms connect, so it cannot
help a worker whose hello costs 4s. Worth separating those two failure classes,
since the retry workaround is being recommended for both.

2. The worker never loses data. Throughout, pid 1509762 stayed alive (2h+)
and kept appending ~500 bytes/5s to its transcript. So the user-visible damage is
a broken supervisor view, not lost work — which matches the "process alive,
listening, no V8 OOM" observation here and the permanently-unopenable session in
#1650.

Related: #1650 (terminal failed descriptor, same lastError), #1641 (reattach
failures after restart), #1730 (a wedged worker blocking startup and stampeding
rival supervisors — which explains the Lock file is already being held bursts I
also saw).

Happy to provide full supervisor/client logs or test any patch on Linux.