Foreground subagents emit stale “needs attention” notices and suggested status action cannot find the run

[Whisperfall]

Description

Foreground subagent runs repeatedly emit a stale Subagent needs attention notice even when the child has already completed, failed, timed out, or written its requested output.

The notice recommends:

subagent({ action: "status", id: "<run-id>" })

However, the parent agent's subsequent status invocation returns:

Async run not found. Provide id or dir.

The same notice also says:

Nudge: no child message route registered

This leaves the parent agent and user unable to determine whether the child is still running, completed, failed, or can be resumed.

Environment

• pi-subagents: 0.26.0
• Foreground subagent runs
• Observed with single, parallel, and story/worker agents
• Models observed: GPT-5.4 and GPT-5.5
• Linux

Reproduction

Run a long foreground subagent, for example:

subagent({
  agent: "worker",
  context: "fork",
  task: "Perform a substantial implementation or review task"
})

Wait until there is no new tool activity for approximately 60 seconds.

A notice appears:

Subagent needs attention: worker
Run: 2d2122ed step 1
Signal: worker needs attention (no observed activity for 69s)
Hint: Inspect status first unless the run is clearly blocked.
Nudge: no child message route registered
Status: subagent({ action: "status", id: "2d2122ed" })
Interrupt: subagent({ action: "interrupt", id: "2d2122ed" })

The parent agent then attempts to inspect the run and receives:

Async run not found. Provide id or dir.

I have also observed the notice after the child had already reported Done, emitted goal_complete, or written the requested output file.

Examples

Completed child followed by stale notice

✓ bmad-dev-story (...) · Done
output: ~/.pi/agent/.../subagent-artifacts/81716e86_bmad-dev-story_0_output.md

This was followed by:

Subagent needs attention: bmad-dev-story
Run: 81716e86 step 1
Signal: no observed activity for 60s
Nudge: no child message route registered

Rejected child followed by stale notice

Error: Acceptance rejected: Failed to parse acceptance-report

This was immediately followed by another Subagent needs attention notice and a status recommendation that could not find the run.

Child wrote output but parent reported failure

In another parallel run, the child executed:

cat > tmp/code-review/edge-case-hunter.md <<'EOF'
...

and emitted:

goal_complete

but the parent still reported the child as failed and later emitted a needs attention notice.

Expected behavior

• A terminal child state such as completed, failed, rejected, interrupted, or timed out should cancel any pending inactivity/attention notices for that child.

• needs attention should only be emitted while the child is still actionable.

• The displayed status command should work for the run type that generated the notice.

• Foreground runs should not be directed exclusively to an async-only status lookup.

• If no child message route exists, the UI should not recommend actions that require that route.

• The UI should clearly distinguish:

  • still running but inactive;
  • completed;
  • completed with partial output;
  • failed;
  • acceptance rejected;
  • timed out.

Actual behavior

• Terminal runs still receive stale inactivity notices.
• The notice recommends a status action that cannot locate the foreground run.
• The notice says there is no child message route while also suggesting actions against the child.
• Parent agents sometimes retry already-completed work because they cannot reliably determine the child state.

Impact

This can cause:

• duplicate subagent executions;
• overwritten output files;
• unnecessary token and API usage;
• 10+ minute waits for work that may already be complete;
• parent agents treating successful work as failed;
• inability to safely decide whether to resume, retry, interrupt, or consume existing artifacts.

Suggested fix

1. Associate inactivity notices with a child lifecycle generation or terminal-state guard.

2. Before displaying a queued notice, verify that:

   • the run is still active;
   • the step is non-terminal;
   • the child route or another valid control path still exists.

3. Remove pending notices when completion, failure, rejection, timeout, or interruption is recorded.

4. Make status resolve foreground runs by run ID, or show an appropriate foreground-specific inspection action.

5. Avoid showing Status and Interrupt actions when they cannot work.

6. Reconcile child output events such as goal_complete and written artifacts before classifying the parent step as failed.

Related symptoms

This appears related to stale control notices, foreground/async run-state separation, and child route cleanup rather than the child model itself.

[josephkEA]

Reproduction confirmed on 0.28.0, foreground single reviewer run with an acceptance contract.

Sequence observed:

1. Child finished its actual work and entered the acceptance finalization loop (which in our case could not converge — see Completion guard rejects successful worker runs with an opaque acceptance-report parse error #264 for that trace).
2. ~60s into a finalization turn the parent received: Subagent needs attention … Signal: reviewer needs attention (no observed activity for 60s), with Nudge: no child message route registered.
3. The notice's own suggested action subagent({ action: "status", id: "8af0fa39" }) returned Async run not found. Provide id or dir. — foreground runs aren't registered in the async store, so the suggested remediation can never work for the run class that produced it.

The nested-events dir existed (/tmp/pi-subagents-uid-1000/nested-subagent-events/<runId>-<token>/ with route.json) but events/ and controls/ were both empty.

Net effect for the orchestrating agent: an attention signal that (a) was stale by the time it was delivered, (b) carries a status command that fails, and (c) has no working interrupt/resume route — pure noise that demands manual triage. Either registering foreground runs for status lookups or suppressing control notices once the foreground tool call has returned would fix the operator experience.