Summary
Programmatic prompts (agent messages from subagents, scheduled follow-ups) queued at an idle session are never delivered until a human types a prompt. In our production sessions, batches of subagent results sat queued for 8+ hours and all flushed in the same second a human message arrived.
Root cause (two code paths in _admitSessionInput)
- After an abort sets
_sessionInputPumpSuspended, a typed prompt clears it (_prompt() path), but a programmatic admission does not: the flag is only cleared for wake: "immediate" turn actions, so queued steer-delivery actions wait forever at idle.
- Worse, and independent of any abort: when an incoming follow-up coalesces into an already-queued owner (same queue key — the normal shape for any scheduler that re-fires, or repeated subagent messages),
_admitSessionInput returns {accepted: false, disposition: "queued"} before any code that schedules the session input pump. Every re-fire is swallowed; nothing ever restarts delivery.
Reproduction is deterministic on a pristine install (stub provider): idle session + queued programmatic agent message → no turn starts within any timeout; a coalescing re-fire also never resumes the pump. A vitest regression that fails on unpatched code is included in PR #895.
Why most users never see it
The trigger requires an idle session receiving only programmatic input with coalescing keys. Interactive users always type (which resumes the pump via _prompt()), so the starvation is invisible to them. Any headless/orchestrated deployment that relies on agent_message or scheduled follow-ups hits it immediately. Issue #823 (queued agent mail trickling one message per turn) looks adjacent to the same pump behavior.
Fix
PR #895 resumes the suspended pump on programmatic admission (matching _prompt()), including on the coalesced early-return path, with a failing-first regression test. Happy to adjust to your preferred shape.
Impact
Any multi-agent/headless deployment: subagent results, scheduled work, and cron-style follow-ups silently starve at idle sessions. For us this froze overnight autonomous operation until a human keystroke.
Summary
Programmatic prompts (agent messages from subagents, scheduled follow-ups) queued at an idle session are never delivered until a human types a prompt. In our production sessions, batches of subagent results sat queued for 8+ hours and all flushed in the same second a human message arrived.
Root cause (two code paths in
_admitSessionInput)_sessionInputPumpSuspended, a typed prompt clears it (_prompt()path), but a programmatic admission does not: the flag is only cleared forwake: "immediate"turn actions, so queued steer-delivery actions wait forever at idle._admitSessionInputreturns{accepted: false, disposition: "queued"}before any code that schedules the session input pump. Every re-fire is swallowed; nothing ever restarts delivery.Reproduction is deterministic on a pristine install (stub provider): idle session + queued programmatic agent message → no turn starts within any timeout; a coalescing re-fire also never resumes the pump. A vitest regression that fails on unpatched code is included in PR #895.
Why most users never see it
The trigger requires an idle session receiving only programmatic input with coalescing keys. Interactive users always type (which resumes the pump via
_prompt()), so the starvation is invisible to them. Any headless/orchestrated deployment that relies onagent_messageor scheduled follow-ups hits it immediately. Issue #823 (queued agent mail trickling one message per turn) looks adjacent to the same pump behavior.Fix
PR #895 resumes the suspended pump on programmatic admission (matching
_prompt()), including on the coalesced early-return path, with a failing-first regression test. Happy to adjust to your preferred shape.Impact
Any multi-agent/headless deployment: subagent results, scheduled work, and cron-style follow-ups silently starve at idle sessions. For us this froze overnight autonomous operation until a human keystroke.