Fix: programmatic prompts (agent messages, scheduled follow-ups) starve at idle sessions after an abort (#1000)

[kaluli123123]

Summary

Programmatic prompts (agent messages from subagents, scheduled follow-ups/heartbeats) queued at an idle session are never delivered until a human types a prompt. In one report, batches of subagent results sat queued for 8+ hours and all flushed in the same second a human message arrived. This is #1000, one of the "related reports" under the still-open tracker #1382 (Complete queued, interrupted, and archived session lifecycle recovery).

Confirmed still present on main (06860844e) with a new regression test suite that reproduces all three shapes described in the original report.

Root cause (_admitSessionInput in packages/coding-agent/src/core/agent-session.ts)

1. requestAbort() sets _sessionInputPumpSuspended = true. A typed prompt clears it via _resumeSessionInputAdmission() (the prompt() path), but a programmatic admission does not: the flag is only cleared when action.payload.kind === "turn" && action.wake === "immediate", so queued follow-ups/steer actions with the default wake behavior wait forever at idle.
2. Independent of any abort: when an incoming follow-up coalesces into an already-queued owner (the normal shape for a re-firing scheduler, or a repeated agent message with the same queueKey), _admitSessionInput returns { accepted: false, disposition: "queued" } before any code that schedules the pump. Every re-fire is swallowed; nothing ever restarts delivery.

History

An earlier PR attempt, #895, proposed a fix and was closed in favor of a maintainer-owned stacked PR, #1162 (part of the merged #1158–#1165 stack for tracker #1382):

This root cause is now covered by maintainer-owned stacked PR #1162 ... We did not inspect or reuse this PR's diff, branch, commits, implementation code, or tests.

#1162 merged, but this specific code path was not part of it — the bug is still live.

Notably, #895's proposed patch toggled _sessionInputPumpSuspended directly without checking _sessionInputSuspendedForUpdateRestart. That flag is a different, deliberate suspension reason (abortForUpdateRestart()) meant to hold queued inputs so they survive into the restart manifest instead of starting a turn during teardown (see the existing guarded call site around line 6197: if (!this._sessionInputSuspendedForUpdateRestart) this._resumeSessionInputAdmission();). Blindly clearing the flag would have silently reintroduced a second bug — a turn starting mid-restart-teardown — while fixing the first one.

Fix

Resume a suspended pump on both paths (the coalesced early return, and the general admission path) via the existing _resumeSessionInputAdmission() helper, gated on: the action is a turn, the session isn't streaming, the pump is actually suspended, and the suspension is not a restart hold.

if (
	!options.restore &&
	options.wake !== false &&
	action.payload.kind === "turn" &&
	!this.isStreaming &&
	this._sessionInputPumpSuspended &&
	!this._sessionInputSuspendedForUpdateRestart
) {
	this._resumeSessionInputAdmission();
	this._scheduleSessionInputPump();
}

(mirrored in the coalesced-owner early-return branch above it).

Tests

Added packages/coding-agent/test/suite/regressions/resume-suspended-input-pump.test.ts with 4 cases:

• delivers a queued agent message at idle after an abort suspended the pump
• delivers backlog queued before an abort once a later programmatic admission arrives
• resumes the pump when a coalesced follow-up re-fires at idle
• does not resume a pump suspended for an update restart — verified this case fails if the _sessionInputSuspendedForUpdateRestart guard is removed, so it actually exercises that hazard

All 4 fail against pre-fix main and pass after the fix. Also ran:

• test/suite/agent-session-queue.test.ts, agent-session-action-contracts.test.ts, agent-session-action-races.test.ts, agent-session-autonomous.test.ts, agent-session-goal.test.ts (195 passed)
• test/suite/regressions/4257-update-restart-resume.test.ts, the existing large update-restart suite (35 passed)
• A broader run of the full packages/coding-agent suite surfaced 3 unrelated pre-existing failures (resource-loader.test.ts, package-command-paths.test.ts, 4600-supervisor-singleton.test.ts); confirmed by re-running them against unmodified main that they fail identically there (sandbox-specific: symlink/extension loading and real daemon-socket timing), unrelated to this change.
• Root npm run check (biome, tsgo --noEmit, installer render, browser smoke) — all green. Added a packages/coding-agent/.changes/ fragment per the changelog-fragment CI check.

Patch

Branch: https://github.com/kaluli123123/prime-agent/tree/fix/resume-suspended-input-pump-programmatic

Diff: main...kaluli123123:prime-agent:fix/resume-suspended-input-pump-programmatic

Happy to open a PR from this branch if a maintainer wants to invite implementation, per CONTRIBUTING.md.