bug(goal-loop): continuations are delivered mid-turn while the agent is still working #1024

Expected

A goal loop delivers its continuation prompt only when the agent has actually stopped, meaning its turn ended. Each continuation marks one real stop.

Actual

In a Claude Code session running a goal loop (started via goal_loop_start at 2026-09-19T05:31:10Z), continuations kept arriving while the agent was mid-turn and working continuously. They show up in the transcript as queued user messages ("sent while you were working") between tool calls.

• ~/.config/agent-code/goal-loop.json shows 33 continuations delivered between 05:31:10Z and 06:37:14Z, about one every 2 minutes, during what was effectively one unbroken working turn.
• The owner noticed it: "some bs condition triggered the loop to continue to iteration 33 when you didn't even stop… must be subagents or something."

Impact

• The budget burns. 33 of 150 continuations went in about an hour with no real stop, so a long loop can hit its cap and pause while work is ongoing.
• Context bloat. Each delivery injects the full loop prompt (goal plus about 3 KB of instructions) into the live turn.
• Misleading. The agent is told "You stopped before this goal was complete" while it is still running.

Root cause (code reading; not yet reproduced in a test)

GoalLoopService treats any semantic working → idle transition as a turn boundary (src/main/goalLoop/GoalLoopService.ts, the path that calls scheduleContinueCheck). #1008 added a one-macrotask deferral for the Claude adapter's single-batch idle blip, but the session here produces real, lasting idle phases mid-turn. Ranked:

1. Background subagents (strongest). Claude Code's Agent tool runs subagents inside the same claude process, so their API traffic flows through the same proxy. A subagent's request→response→stop reads as the parent session going working→idle. The parent turn is still open, and the parent's pendingTools does not cover a background subagent, so the guard does not hold. This session had up to 3 background subagents running at a time.
2. Long foreground tool calls. A 5–10 minute Bash command (a test run) leaves the stream idle between API requests. If the tool_use is not tracked into pendingTools for every tool type, for example MCP tools, the gap reads as a turn end.
3. Background task notifications. A background-task completion restarts the model mid-turn and can produce a short working→idle cycle.

Whichever it is, the design flaw is the same: the loop infers "turn ended" from stream phases, which are not turn-scoped for Claude Code.

Fix direction

• Claude: use Claude Code's Stop hook as the authoritative turn boundary. Agent Code already runs hook endpoints, for example /hooks/tldr/stop. Stop fires only when the MAIN agent's turn ends, and SubagentStop is separate. Stream phases can stay a fallback for providers without such a signal, never the primary one.
• Every provider: deliver only when the agent's input is idle, with no queued input and the composer not in a working state, so a continuation can never enter a live turn.
• Tests: replay a recorded Claude session that runs a background subagent and a long tool call through the service, and assert exactly one continuation per real stop.

Environment

macOS, a dev build of main (after #1019), a Claude Code session in Agent Code, and a goal loop with maxContinuations 150.