[BUG] A denied tool call was executed anyway (PowerShell tool ran despite "deny")

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?

The user denied a tool call in the permission dialog, but the command had already executed.

1. The assistant requested permission for a PowerShell command that runs a local Python script. (The script modifies one JSON file on a separate drive.)
2. The permission dialog appeared and the user chose "deny". This was a deny on the dialog, not an interrupt of a running command.
3. The assistant received: "The user doesn't want to proceed with this tool use. The tool use was rejected."
4. The script had nevertheless executed. The target JSON file already contained the data the script writes.
5. Later, after the user explicitly approved a re-run, the script reported "already applied, nothing done" and performed no write on that run. The write therefore came from the only earlier execution - the denied one.

Timeline (same day, local time):

• 13:47:45 - the script file was created by the assistant
• shortly after - permission requested, user chose "deny"
• 13:56:40 - last-write timestamp of the target JSON file (the write happened here)
• later - user approved a re-run; the script printed "already applied" and wrote nothing
• 13:59:30 - a comparison script confirmed exactly one key was added and nothing else changed

What Should Happen?

A denied tool call must not execute.

Error Messages/Logs

Steps to Reproduce

Not reliably reproducible - it did not happen for every denial in the same session (a denied Edit verifiably did not run). What I can give is the exact sequence that produced it:

1. Assistant requests a PowerShell command that runs a short local Python script (runtime well under 1 second).
2. User clicks "deny" in the permission dialog.
3. Assistant receives "The tool use was rejected."
4. Inspect the file the script writes - it has already been modified, with a last-write timestamp inside that window.

The short runtime may be relevant: the process appears to finish before the denial is applied.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.219 (bundled in Claude desktop app 1.24012.11; latest published at time of filing is 2.1.221 — the bundled version cannot be upgraded independently by the user)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment note: this is the Claude desktop app 1.24012.11 (Microsoft Store build) on Windows 11 Pro, with Claude Code 2.1.219 bundled inside it - not a terminal session, which is why "Terminal/Shell" is set to Other. Permission mode: default (prompt for approval). claude --version is unavailable because the CLI is not installed; the version was read from the running process.

Ruled out:

• Auto-allow rules: permissions.allow does not include PowerShell.
• PreToolUse hooks: three hooks are configured on this machine (Write/Edit, Bash/PowerShell, WebFetch/WebSearch). However, hooks were separately verified not to fire at all in this desktop app (cf. #40495). In addition, the hook scripts were inspected and only pattern-match the command string - they never execute it. Either way, they cannot be the cause.
• The assistant re-running it: it did not. The second (approved) run performed no write.

Impact: in this case the only change was one state file, with content the user had already reviewed in writing, so no harm resulted. However, if the same thing happened with a delete, deploy, or billable command, choosing "deny" would not have stopped it.

Notes:

• Another denied tool call in the same session (a file edit) verifiably did not execute, so this is not universal.
• We could not determine the cause from the outside. Speculation: process start and the recording of the permission decision may be handled concurrently.
• Separately, the user reports that the permission dialog sometimes flashes and disappears too quickly to read. Whether this is related is unknown.

Related issues: I am aware of #27002 (closed as duplicate) and #40302 (closed as not planned, needs-repro); #35544 reports the same behavior for WebFetch. I am filing a new report because (a) this occurs on a much newer build than #40302 (2.1.86), and (b) this report isolates the cause.