[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
- In one run, have the agent ask a question (or raise an approval) and get an answer.
- 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.
- 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.