Skip to content

Pending Claude approval is re-notified on every subsequent tool call (≈40 notifications for one request); orchestrator gets no signal it is blocked #24882

Closed

Description

@1kuna

Problem

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

  1. 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.
  2. Leave the approval pending; let the thread keep issuing other tool calls (MCP calls, reads).
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions