[Juliusolsson05]

Problem (#1138, class C1)

The goal loop continued the moment Claude's turn ended, even while the agent had async subagents or run_in_background shells that the CLI will wake it for with a task-notification. Each continuation in that gap got "still waiting" and cost one continuation (observed three in a row, 2026-09-22).

Evidence (staged decomposition; details in the #1138 comment)

• Claude Code 2.1.280+ puts background_tasks on the Stop hook payload. Its own schema: lets hooks distinguish 'session is done' from 'session is paused waiting for background work to wake it'.
• Captured unedited from 2.1.282 and saved as testing/fixtures/goal-loop-stop-hooks/claude-2.1.282.json:
  • [] when idle;
  • a running shell;
  • a running subagent;
  • a subagent's leftover shell after it finished.
• Corpus: 807 transcripts. 97.4 % of 1,964 background launches pair with a delivered notification, and 33 % of main turn ends had background work pending.
• Codex: child final answers carry trigger_turn:false, so a finishing child never wakes the parent. No change is needed there.

Change

• BuiltInMcpHttpHost forwards background_tasks from a Stop. A missing or malformed field means unknown and isn't forwarded, so an older CLI behaves exactly as today.
• GoalLoopService holds (background-work) while the last allowed Stop reported a running or pending shell, subagent, workflow or MCP task. The notification turn's own Stop replaces the set, and an empty list releases the hold.
• Monitors and unknown kinds are not held on, since a persistent monitor never ends.
• Background work is exempt from the 30-minute silence pause, like a running tool. Otherwise the loop would be paused when the notification turn arrives. The 2-hour absolute limit still applies.
• The set is cleared on a stalled-hold pause (a Resume means continue anyway) and when the session's process dies.

Tests (fail-first, real payloads)

• The service replays the captured Stops:
  • holds on a shell;
  • holds on a subagent;
  • continues when the field is absent;
  • doesn't hold on a monitor;
  • isn't paused for silence but is by the absolute limit.
• The real MCP host over real HTTP carries the payload through to the loop.

Mutation-checked, each individually: host drops the field, silence not exempt, hold on monitors. Each turns a test red.

Verification

npx tsc -b clean; src/main/goalLoop passes (4 files, 69 tests).
Not verified here: a live overnight loop. The 11 % case (a notification already queued at Stop) isn't in background_tasks; the CLI wakes the agent immediately there, so the existing turn-open gate handles it.

Fixes #1138

🤖 Generated with Claude Code

Review disposition (A Pi, B Grok, C Pi; 2 rounds, plus steering)

Finding	Disposition
A1/B1 MAJOR: the Monitor tool arrives as shell (verified in the 2.1.282 binary); a never-ending shell parked the loop for 2 h, paused it, and re-parked after every Resume	Fixed (ac45391a): each report holds for GOAL_LOOP_BACKGROUND_WORK_LIMIT_MS (45 min), then DELIVERS; the next Stop opens a fresh window. Corpus: 92–94% of background tasks notify within 45 min
A2: a stale latch stretched a silent turn-open hold to 2 h	Fixed: the gate and the silence exemption both use the expiring backgroundWorkHolds()
A3/C2: an unreadable Stop body released the hold	Fixed: unknown keeps the latch. The host treats a non-empty list with ANY unreadable entry as unknown (steering q5, 474ae837)
A4/B/C test gaps: workflow, MCP task, pending, leftover-shell fixture, process death, host keep-on-unknown	Fixed; each has a test and a killed mutant
C6: no trailing newline in the fixture	Fixed
Round 2 (A, C): a chain of refreshed reports can still reach the 2 h pause	Accepted by design (visible, resumable backstop). The comment is corrected (52bbd30a)
Round 2 (C): an unattended loop beside a never-ending shell spends its cap in about 19 h	Accepted: cap-pause is visible and the cap can be raised

Round 2: A, B and C all MERGE-READY. The steering note q5 was applied after round 2, with a test and a mutation check.