Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Parallel tool-use batches bypass user rejection — denied calls don't cancel siblings in the same block [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#49667•Fetched 2026-04-17 08:34:43
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
jbcdejbcde
Participants
jbcdejbcde
Timeline (top)
labeled ×4

Error Message

Error Messages/Logs

Fix Action

Fix / Workaround

When Claude dispatches multiple tool calls in a single parallel tool-use block, rejecting one call in the permission prompt does not cancel the others. Sibling calls in the same block continue to execute and return their results to the model. Denial only gates calls that have not yet been dispatched — it does not recall calls already in flight within the batch.

When a parallel tool-use block contains any call that requires user confirmation, no call in the block should begin executing until the user has responded to every prompt for that block. Confirmation must gate dispatch, not run alongside it. If any call in the batch is denied, none of the calls run; only after all required approvals are granted does the batch execute.

RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

When Claude dispatches multiple tool calls in a single parallel tool-use block, rejecting one call in the permission prompt does not cancel the others. Sibling calls in the same block continue to execute and return their results to the model. Denial only gates calls that have not yet been dispatched — it does not recall calls already in flight within the batch.

Environment: Claude Code [2.1.112], [Debian 6.12.74-2 (2026-03-08) x86_64 GNU/Linux], model: Claude Opus 4.7 (1M context).

What Should Happen?

Expected behavior:

When a parallel tool-use block contains any call that requires user confirmation, no call in the block should begin executing until the user has responded to every prompt for that block. Confirmation must gate dispatch, not run alongside it. If any call in the batch is denied, none of the calls run; only after all required approvals are granted does the batch execute.

Error Messages/Logs

Steps to Reproduce

  1. Start a Claude Code session in a project where the model is likely to issue a large parallel batch of tool calls (e.g. a CLAUDE.md that instructs the model to read many files on startup).
  2. Prompt the model in a way that causes it to issue many tool calls in a single parallel block — for example, ask it to read a dozen specific files at once, or trigger a startup directive that does so.
  3. When the permission prompts begin appearing, reject them as they come in.
  4. Observe that some of the sibling calls in the same parallel block complete successfully and return their results to the model, despite other calls in the same block being denied.

Observed: Six of thirteen Read calls against files in my home directory completed and returned contents to the model while I was actively rejecting prompts from the same batch.

Expected: No call in the batch should execute until every prompt in the batch has been approved; any denial should cancel the entire batch.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.112 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Windows Terminal

Additional Information

No response

extent analysis

TL;DR

The issue can be mitigated by modifying the parallel tool-use block to wait for user confirmation before dispatching any calls.

Guidance

  • Review the code that handles parallel tool-use blocks and modify it to introduce a gating mechanism that waits for all required user confirmations before dispatching any calls.
  • Investigate the use of asynchronous programming techniques, such as promises or callbacks, to manage the execution of tool calls and ensure that they are properly cancelled when a denial occurs.
  • Consider implementing a transactional approach, where all calls in a batch are treated as a single unit of work, and if any call is denied, the entire batch is rolled back.
  • Verify that the modified code correctly handles the case where a user denies a call in a parallel block, and ensure that no calls in the block are executed.

Example

# Pseudocode example of a gating mechanism
def execute_parallel_tool_use_block(calls):
    # Wait for all required user confirmations
    confirmations = []
    for call in calls:
        confirmation = request_user_confirmation(call)
        confirmations.append(confirmation)
    
    # If any call is denied, cancel the entire batch
    if any(not confirmation for confirmation in confirmations):
        return []
    
    # Execute the calls in the batch
    results = []
    for call in calls:
        result = execute_call(call)
        results.append(result)
    
    return results

Notes

The provided information does not include the exact code that handles parallel tool-use blocks, so the suggested modifications are general and may need to be adapted to the specific implementation.

Recommendation

Apply workaround: Modify the parallel tool-use block to wait for user confirmation before dispatching any calls, as this approach ensures that no calls are executed until all required approvals are granted.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING