Idle `turn` notifications skip before_agent_start (pi#5581): breaks pi-claude-bridge and drops system-prompt extensions

[BGamboa13]

Summary

When a process notification with attention turn fires while the agent is idle, sendProcessNotificationMessage calls pi.sendMessage(message, { triggerTurn: true, deliverAs: "steer" }). On an idle host, Pi starts that run through sendCustomMessage → _runAgentPrompt, which skips before_agent_start (earendil-works/pi#5581, still open on Pi main). Any extension that sets or extends the system prompt in before_agent_start is missing from that turn.

With pi-claude-bridge the turn is rejected outright, and the session stops until the user types something:

Error: prompt-capture: no capture for this 69174-char system prompt, and it embeds none of the 10 known.
Closest known match diverges at offset 69174 (71847-char key, last recorded at turn_start). ...

The prompt is the captured one minus its final 2673 characters: exactly the section other extensions append in before_agent_start. With other providers the turn runs, but silently without those additions (see the cache-cost reports in pi#5581).

Reproduce

Pi 0.99.1 / 0.99.2, @aliou/pi-processes 0.12.0, any extension that returns systemPrompt from before_agent_start (pi-claude-bridge 0.9.0 shows it as a hard error):

1. Start a short process with default attention (onSuccess: "turn"), e.g. sleep 5.
2. Let the agent end its turn and go idle.
3. When the process exits, the woken turn runs without before_agent_start.

main (510e9bc) is affected at extensions/processes/notification-sender.ts:26 (return { triggerTurn: true, deliverAs: "steer" }) and :39 (pi.sendMessage(...)). #116 keeps the same turn options, so it stays affected after that rewrite.

Suggested fix

This is the workaround documented in pi#5581 (comment by @tenshiak), already used by gentle-pi (Gentleman-Programming/gentle-shell#1595). When the host is idle, queue the notification for the next turn and start the turn through sendUserMessage, which goes through prompt() and therefore runs before_agent_start:

if (options.triggerTurn && ctx?.isIdle()) {
  pi.sendMessage(message, { deliverAs: "nextTurn" });
  pi.sendUserMessage(" ");          // prompt() → before_agent_start
} else {
  pi.sendMessage(message, options); // unchanged while a run is active
}

Two details matter in practice:

• Coalesce wakes. prompt() awaits input handlers, auth, compaction and before_agent_start before it marks the run active, so isIdle() still reads true while the first wake is being prepared. A second process exiting in that window would submit a second sendUserMessage, which is rejected ("Agent is already processing"). A synchronous reservation fixes it: set it on the first wake, release it on agent_start/session_start, and let it expire after ~60 s. Later notifications are only queued as nextTurn, and the pending prompt carries them.
• Where to read isIdle(). The notification fires outside any handler, so it needs the latest ExtensionContext. Tracking it from session_start/agent_start/turn_end/agent_end, registered at extension load in registerNotificationDelivery, works. If no context has been seen yet, keep the original sendMessage call.

I'm running this as a local patch (about 40 lines in notification-sender.ts plus one call in handlers/notifications.ts). I checked it with a small harness: busy host unchanged, idle host woken once, a second idle notification coalesced, the reservation released on agent_start, and context attention unchanged. Happy to open a PR with tests, on main or on top of #116, whichever you prefer.

[aliou]

hello @BGamboa13 , i'm away from a screen right now and haven't looked at the code but can you check if #116 fixes this?

edit: and i apparently can't read since you mention 116 i'm guessing you already tried 😅

[BGamboa13]

No worries, thanks for looking! I re-checked against #116's current head (12cab67d) to be sure: it doesn't cover this case.

#116 changes context and ignore to { triggerTurn: false }, but turn is unchanged. attentionToSendOptions still returns { triggerTurn: true, deliverAs: "steer" } (notification-sender.ts:32), and it still goes through the same pi.sendMessage call (:45). When the host is idle, Pi starts that run via sendCustomMessage → _runAgentPrompt, which skips before_agent_start. So the default onSuccess: "turn" wake-up still loses everything extensions add to the system prompt there. With pi-claude-bridge, that turn is rejected outright.

The fix is orthogonal to #116. When the host is idle, queue the notification as nextTurn and start the turn with sendUserMessage, coalescing wakes so two processes exiting together don't race into "Agent is already processing". It only touches the turn path, so it should rebase cleanly whichever lands first. Gentle Pi merged the same pattern for its subagent completions in Gentleman-Programming/gentle-shell#1631, if you want a reference.

I'll open a PR against main with tests shortly. If #116 lands first, I'll rebase onto it, or move it on top of #116 if you'd rather.