Tool calls rejected with 'user doesn't want to proceed' when user didn't reject

Bug: Tool calls rejected with "user doesn't want to proceed" when user didn't reject

Environment

• Claude Code version: 2.1.62
• OS: Windows 11 Pro 10.0.26200
• Shell: Git Bash
• Model: claude-opus-4-5-20251101

Description

Tool calls are being automatically rejected with the message "The user doesn't want to proceed with this tool use" even though the user did not reject them and saw no approval prompt.

Steps to Reproduce

1. Start a new Claude Code session
2. Attempt to run a Bash command with a long timeout parameter:

``
Bash(command="python deploy/deploy.py", timeout=300000)
``

1. The tool call is rejected with "The user doesn't want to proceed"
2. User sees no prompt to approve/reject - the rejection happens silently

Observed Behavior

• Multiple consecutive Bash calls with timeout=300000 were rejected
• User confirmed they were not rejecting ("not IM NOT", "there is nothing on my end")
• No approval prompt was displayed to the user
• Simple commands without timeout parameter worked fine (echo "test")
• After some successful simple commands, the original command worked without timeout parameter
• TaskOutput tool call was also rejected under similar circumstances
• Read tool on the same output file worked fine

Expected Behavior

• User should see an approval prompt if the command needs approval
• Commands matching the allow list (Bash(python:*) was configured) should execute without prompting
• If rejection occurs, it should be because the user actually clicked reject

Configuration

Settings include:

{
  "skipDangerousModePermissionPrompt": true,
  "permissions": {
    "allow": [
      "Bash(python:*)",
      ...
    ]
  }
}

The command python deploy/deploy.py should match Bash(python:*) and execute without prompting.

Investigation Performed

Ruled out:

• Hookify plugin: No .claude/hookify.*.local.md rule files exist
• Superpowers plugin: Only has SessionStart hook (context injection), no PreToolUse hooks
• Permission mismatch: Pattern Bash(python:*) is in allow list and works in later attempts
• Statusline script: Only displays git branch and context info

Possible Causes

1. Race condition at session start affecting permission evaluation
2. Long timeout values (300000ms) triggering unexpected behavior
3. Interaction between timeout parameter and permission matching logic
4. Internal state corruption causing auto-rejection before prompt is shown

Workaround

• Omit the timeout parameter on Bash calls
• Run a few simple commands first before attempting longer-running commands
• Use run_in_background instead of timeout for long-running commands

Impact

This bug caused significant time waste and user frustration. A production deployment that should have taken 2 minutes took over 20 minutes due to repeated mysterious rejections.