False 'tool use rejected by user' errors when user took no action

Bug Description

During a session, multiple consecutive Bash tool calls returned the error:

"The user doesn't want to proceed with this tool use. The tool use was rejected"

The user did not reject anything. No permission prompt was shown to the user, and the user was not typing or interacting with the CLI at the time. The user confirmed repeatedly they saw no prompts and took no action.

Reproduction

1. Start Claude Code with --dangerously-skip-permissions (full permissions mode)
2. Have hooks configured (PreToolUse hooks present in .claude/hooks/)
3. Send a message that triggers multiple Bash tool calls
4. Tool calls return "rejected by user" error without any user interaction

What Happened

• 4-5 consecutive Bash tool calls (simple curl commands) were all "rejected"
• The error message falsely claimed the user rejected them
• No permission UI was shown to the user
• After several conversation turns, subsequent Bash tool calls worked normally
• The session had multiple startup hooks running (pre-bash-guard.sh, session-bootstrap.sh, etc.)

Expected Behavior

• Tool calls should execute without false rejection errors
• If a tool call is blocked by a hook, the error should indicate the hook blocked it (not "user rejected")
• If there's a race condition at startup, it should be handled gracefully

Environment

• Claude Code CLI (latest as of Feb 2026)
• macOS (Darwin 24.3.0)
• Permission mode: --dangerously-skip-permissions
• Multiple PreToolUse and UserPromptSubmit hooks configured
• Model: claude-opus-4-6

Possible Causes

• Race condition between startup hooks and first tool calls
• Hook execution being misinterpreted as user rejection
• Some internal state not fully initialized when first tool calls fire