[Bug] Parent agent_message nudges can sit in a child's queue forever after the child goes idle

[Dmatut7]

What happens

When a parent RLM session assigns work to a child and later nudges it with agent_message, the nudge often never reaches the child's next turn. The child looks stuck. The parent waits, sends another nudge, and that one queues too. In the TUI this shows as a long Waiting · … on the child plus queued chips that never drain.

This is not one failure. Three things stack:

1. The child can sit in a long turn (model wait, long IPython/bash, tool loop). Parent nudges are correctly refused mid-turn and go into the session action queue.
2. After that turn actually ends, nothing starts the child's input pump, so the queued parent messages stay queued while the child is idle.
3. The parent cannot tell "idle with undelivered mail" from "still working", so it nudges again and the queue grows.

We are asking whether (2) is intended, and what the supported recovery path is for a headless child (no human Enter on that session).

Steps to reproduce

1. From a parent session, spawn an RLM child and give it a long task (await rlm(...), child replies with agent_message.send(..., receiver_role="parent")).
2. While the child is mid-turn, from the parent send await agent_message.send("please report status", receiver_role="child", ...).
3. Wait until the child finishes its current turn. Do not type into the child TUI. Do not press Enter / Ctrl+C on the child.
4. From the parent, send a second nudge.
5. Inspect the child: queuedCount / queued message chips, and whether the first nudge ever appears in the child's transcript.

Expected

Once the child is idle and not abort-suspended, queued parent agent_messages should start a turn (or there should be a documented, automatic drain for programmatic senders). The parent should be able to tell the child is idle-with-queue vs still running.

Actual

• First nudge returns queued.
• After the child goes idle, the nudge still does not appear as a user/custom turn.
• Later nudges also return queued (unfinishedActionCount > 0 keeps acceptAgentSessionMessage on the queue path).
• Child journal then sits on repeated agent_status with taskState: "needs_input" and summary: "".
• Parent keeps waiting for a reply that the child never reads.

What we already ruled out

We scanned ~320 local session journals (parent + children).

• No durable "toolCall without toolResult" hang that lasted until kill. The few dangling toolCall ids we found were aborted/terminated streams that the next turn recovered from.
• No permission-denied or observe-skill host failures. The only agent_observe error we saw was the model calling recent_messages(name=...) instead of target=.
• Provider 429s happen under many children, but they recovered in ~15s and were not the stuck-queue mechanism.

So the user-visible "child is stuck and my nudge cannot get in" is a delivery / scheduler problem, not a missing tool timeout.

Code path (current main)

Parent send: DaemonMode.acceptAgentSessionMessage (packages/coding-agent/src/modes/daemon/daemon-mode.ts).

• Busy / already-accepting / unfinishedActionCount > 0 → queueAgentMessagePrompt(prompt, "steer").
• Idle → acceptAgentMessagePrompt(...) with resumeIfIdle hardcoded false.

Queue admission: AgentSession._admitSessionInput (packages/coding-agent/src/core/agent-session.ts).

The pump is scheduled only when:

• disposition === "starts_when_admitted", or
• delivery === "next_turn_boundary" && this.isStreaming, or
• session command, or
• wake === "immediate".

queueAgentMessagePrompt does not pass immediatelyEligible or resumeIfIdle. Steer therefore gets wake: "on_lower_boundary". That wakes the pump only while the child is still streaming.

We then could not find any _scheduleSessionInputPump() on a normal agent_end. Other call sites exist (compaction, bash end, refine, resumeQueuedWork, waitForIdle waiters). After a clean turn end, a steer that arrived mid-turn can sit in the store with nobody selecting it.

wake === "immediate" also calls _resumeSessionInputAdmission(), which clears _sessionInputPumpSuspended. That looks like the reason acceptAgentMessagePrompt forces resumeIfIdle: false: a child/parent message must not undo a user Ctrl+C. We do not want to flip that blindly.

Related, not the same report

• #1761 — programmatic prompts starve after abort because the pump stays suspended. Overlaps the "no human Enter" problem. #1519 only helps an attached TUI (Enter → resume_queue). A parent cannot press Enter in the child.
• #1752 — unbounded empty agent_status writes when prime-inference has no auth. We hit the same journal (thousands of identical needs_input / summary: "" rows). It makes idle children look busy/stuck in the tree and burns disk. Not the queue-drain bug.
• Tracker #1382 — queued / interrupted session recovery.

Questions for maintainers

1. After a normal agent_end (no abort, no update-restart), should queued parent agent_messages drain automatically? If yes, is _scheduleSessionInputPump() on agent_end (no-op while _sessionInputPumpSuspended) the intended fix, or is there another wake we missed?
2. Is acceptAgentMessagePrompt({ resumeIfIdle: false }) only meant to preserve Ctrl+C / update-restart holds? If so, should idle + not-suspended parent→child still use immediatelyEligible / schedule the pump without clearing the abort flag?
3. For a detached child, what is the supported way for a parent to say "read your queue now"? resume_queue exists, but agent_message does not call it, and #1519 is TUI-only.
4. Should agent_observe expose something like queuedCount + idleMs / last activity so a parent can tell "queued and idle" from "still in a turn"? The list summary already has isStreaming / queuedCount, but nothing that means "pump parked" or "last message age".

Happy to open a PR if you want implementation on a specific option. We would rather not guess the abort / update-restart invariants.

Environment

• Prime Agent version: 0.8.0 (coding-agent tree matching current main)
• OS: macOS
• Setup: daemon + parent RLM session with several children, parent nudges via agent_message