Background agent notifications treated as stale after session/prompt response #441

Checklist

• I agree to communicate with the author myself (not AI-generated).
• I've read the README's Filing issues section.
• I'm running the latest versions (fill in below).
  • agent-shell version: 0.50.1
  • acp.el version: 0.2.1
  • ACP package: opencode-acp (bundled with opencode)
  • Agent CLI version: opencode 1.2.27
• For requesting new agent support, I'm including a link to the ACP-capable agent or related ACP package.
• For issues, I'm including ACP traffic (as per README).

Description

Related: #384 (similar symptom, different cause)

When opencode agent uses background tasks, session/update notifications continue arriving after the main session/prompt response. These are all silently discarded as "stale" and logged to *Messages* instead of being rendered in the shell buffer.

Note: This only affects agents that send the response before background tasks complete. For example, claude-code appears to wait for all background agents to finish before sending end_turn, so this issue does not occur there. OpenCode sends the response as soon as the main turn completes, while background agents keep running and producing notifications.

Root cause: agent-shell--on-notification checks agent-shell--active-requests-p at lines 1385, 1438, 1470, and 1546. Once the session/prompt response arrives, the request is removed from :active-requests, and all subsequent notifications hit the stale branch.

Repro steps

1. Use opencode
2. Send a prompt that triggers a background task (e.g. "spawn a subagent running sleep 10 && echo "done" in the background")
3. Wait for the main turn to complete (response arrives)
4. Wait for the background task to finish
5. Check *Messages* — notifications show up as "Thought process (stale, consider reporting to ACP agent)" / "Agent message (stale, ...)"

ACP traffic

14:58:05.694 ← response     result          ← main turn ends here
14:58:52.008 ← notification session/update  ← background task notifications
14:58:52.036 ← notification session/update     start arriving, all treated
...                                             as stale
14:59:02.806 ← notification session/update

Note:

Using a prompt like "spawn a subagent running sleep 10 && echo "done". but not as a background job" behaves correctly as in this case the end_turn comes after the subagent has finished.

Possible fix

The notifications aren't actually stale — they belong to a legitimate background task. The active-requests-p check is too strict. Possible approaches:

• Render notifications without an active request (perhaps in a dedicated section)
• Track background activity separately from :active-requests