[Bug]: A second request right after the first in the same run doesn't notify #32711

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. In one run, have the agent ask a question (or raise an approval) and get an answer.
2. In the same run, have it ask a second question straight away, before the client sees the thread go back to working. Two approvals raised back to back by parallel tool calls should show it.
3. Keep the T3 window in the background, so notifications are allowed.

We found this by reading the source, and haven't reproduced it in a run yet.

Expected behavior

Each new pending request notifies, as the first one did.

Actual behavior

Only the first notifies. The gate compares an attention key built from the run and status: apps/web/src/components/ThreadNotificationCoordinator.tsx:255, ${runId}:${status}. It notifies only when that key changes (ThreadNotificationCoordinator.logic.ts:30). If the client never sees a non-attention state between the two requests, the key stays run:input (or run:approval), and the second request is silent.

Impact

The second question in a run is easy to miss: it shows a badge, but no sound or notification. It happens rarely, but when it does the agent sits blocked.

Version or commit

v0.1.8-nightly.20261106.4247 (e136e8e3d4); the same code is on main at a9e709f.

Environment

T3 Code desktop on macOS, server on Linux; Claude Opus 5.5 threads.

Workaround

None in the client. We watch the sidebar badge.

Suggested fix

Include the pending request's id in the attention key, so each new request gets its own key.

Written with Claude Opus 5.5 in T3 Code; GPT-6.1 Sol traced the source.