You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pending Claude approval is re-notified on every subsequent tool call (≈40 notifications for one request); orchestrator gets no signal it is blocked #24882
When a Claude Code tool call in a T3 thread waits on a user approval, T3 keeps re-announcing that one pending approval. On 2026-10-25 a full-access Claude thread (Opus 5.5, --permission-mode bypassPermissions) hit Claude Code's bypass-immune dangerousRemoval safety check on one Bash call at 09:42Z. That single request (T3 orchestration_v2_projection_runtime_requests: kind command, one row) stayed pending until the user accepted it at 13:22Z. During that window the user's lock screen showed "Approval: " notifications in pairs, about forty in total by their count, timed with the thread's other parallel tool calls, while the orchestrator itself had no signal that one of its calls was blocked and kept working around it for 3 h 40 min.
The user's reaction, verbatim, was to threaten the thread; the thread had asked once.
Reproduction
Full-access Claude thread. Run a Bash command Claude Code's dangerousRemoval breaker flags (an rm whose target is a shell variable, e.g. rm -rf "$TMPDIR/x"). Claude Code asks even in bypass mode.
Leave the approval pending; let the thread keep issuing other tool calls (MCP calls, reads).
Watch macOS notifications: the same pending approval is announced repeatedly.
Proposed behavior
Notify once per pending approval, with a single reminder at a long interval if still pending; coalesce by request id.
Show the pending approval to the thread itself (a tool result or injected notice: "your call <id> is waiting on user approval since ") so an orchestrator can route around it or ask the user once, instead of silently waiting hours.
Surface the approval reason Claude Code supplies (decisionReason.reason, here "Dangerous rm operation …") in the approval card and the notification so the user knows what they are approving.
Why this belongs in T3
T3 owns the notification channel and the only view of the pending request; neither the model nor the user can de-duplicate it, and the model cannot see that its own call is blocked.
Activity