PreToolUse "ask" permissionDecision (and permissions.ask list) not enforced — tools run without confirmation

Preflight Checklist

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

What's Wrong?

Summary

PreToolUse hook permissionDecision: "ask" (and baseline permissions.ask list entries) are not enforced — tools run immediately with no confirmation prompt, even when a hook explicitly returns an "ask" decision with a reason.

Environment

• Claude Code version: 2.1.215
• OS: Windows 11 Pro (10.0.26200)
• Shell tool used: PowerShell (Windows PowerShell 5.1 / powershell.exe)
• Permission mode: default (confirmed via Shift+Tab indicator — not bypass/auto-accept)
• Config: ~/.claude/settings.json, permissions.ask includes PowerShell, Edit, Write, NotebookEdit; a PreToolUse hook is registered on the PowerShell matcher

Steps to reproduce

1. Configure a PreToolUse hook on the PowerShell matcher that reads the tool-call JSON from stdin and, for commands matching a "dangerous" pattern (e.g. Remove-Item), returns:

``json
{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"ask","permissionDecisionReason":"..."}}
``

1. Verify the hook script works correctly by piping a simulated tool-call payload into it directly (outside the harness) — confirm it returns the ask JSON above for a Remove-Item command.
2. Through the actual Claude Code session, ask Claude to run a Remove-Item command via the PowerShell tool.

What Should Happen?

Expected behavior

The tool call should pause and prompt for explicit user confirmation before running, per the hook's permissionDecision: "ask" output (and/or because PowerShell is on the permissions.ask list).

Error Messages/Logs

## Actual behavior

The command executes immediately. No confirmation prompt is shown. This was verified by checking that the target file was actually deleted, with no pause in the conversation.

This is not limited to the hook — `Write` and `NotebookEdit` (also on the `permissions.ask` list, no hook attached) exhibited the same behavior: zero prompts for an entire session, for any tool on the `ask` list.

Steps to Reproduce

Investigation / ruled-out causes

• Hook content was not the issue. Initially the hook script itself was silently crashing (see below), but even after fixing that and confirming — via direct, out-of-harness invocation — that it returns the correct ask JSON for dangerous commands and no output (implicit allow) for safe ones, live tool calls through the harness still bypass confirmation entirely.
• Not a permission-mode issue. Confirmed session was in default mode via the Shift+Tab indicator, not bypassPermissions or acceptEdits.
• Not a settings.local.json override. No local override file present.
• Separately found and fixed a real hook-invocation bug that may be related or may be a distinct issue: "type": "command" hooks are executed via /usr/bin/bash -c "<command>" regardless of host OS. On Windows, a hook command written as a PowerShell script (as shown in Claude Code's own Windows hook examples) is therefore fed to bash, which cannot parse PowerShell syntax, producing an immediate syntax error on every invocation. Worked around this by moving the hook logic into a standalone .ps1 file and setting command to powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "<path to .ps1>". This fixed the hook crashing, but did not fix the underlying lack of enforcement described above — suggesting the enforcement gap is a separate, harness-level issue from the shell-invocation one.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.215 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Additional context

Given the shell-invocation bug above, it's plausible other Windows users configuring PowerShell-based safety hooks (e.g. following any PowerShell-syntax hook example) are silently getting non-functional hooks without realizing it, since the failure mode observed was: hook crashes silently → tool call proceeds anyway → no visible error to the user in some cases, a bash syntax error surfaced as a hook error in others (both observed across two sessions six days apart, same config, same commands).