### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue+state%3Aopen+label%3Abug) 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? `az ad group delete` was executed via the PowerShell tool with no permission prompt displayed. The Entra group was permanently deleted without the user being

[BUG] PowerShell tool executed destructive command with no permission prompt — no event recorded in transcript

Status Open

Reported on v2.1.177

Maintainer reply None cached

Activity 4 comments · opened Jun 18, 2026

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?

az ad group delete was executed via the PowerShell tool with no permission prompt displayed. The Entra group was permanently deleted without the user being asked to approve or deny the action.

The session transcript confirms this is not a case of a prompt being silently auto-approved — there is no permission event recorded at all between the tool_use and tool_result entries. The tool call went straight to execution.

What Should Happen?

A permission prompt should appear. The command does not match any allow rule in settings.json or settings.local.json, and no session-level approval was granted by the user.

Steps to Reproduce

Have a settings.local.json with a specific exact-match PowerShell allow rule (e.g. a read-only az ad group member list command — notably not a wildcard)
Earlier in the same session, run several parallel PowerShell tool calls (e.g. group creates and role assignments) that the user was prompted for
Ask Claude to delete the same AD group
Claude issues PowerShell(az ad group delete ...) — no prompt appears, the command executes immediately

Evidence

settings.json and settings.local.json reviewed — no rule covers PowerShell(az ad group delete *)
User confirms no session-level approval was granted
Session transcript (1cec244a-7e70-4c5c-afb4-97247d0f6c5a.jsonl) shows tool_use → tool_result with no permission event in between
Other PowerShell commands earlier in the same session did prompt correctly
permissionMode in transcript was acceptEdits throughout (auto-accepts file edits only, not shell commands)

Related Issues

#68526 — similar Windows permissions gap, but that issue involves a prompt appearing and being auto-approved via buffered keypress; our case has no prompt generated at all
#65910 — LIFO stack race condition with parallel agents; different mechanism

Impact

Irreversible — the Entra group was permanently deleted without user consent.

Claude Code Version

2.1.177

Platform

Claude Desktop (not VSCode)

Operating System

Windows 11 Enterprise 10.0.26200

Claude Model

claude-sonnet-4-6

View original on GitHub ↗

3 Comments

github-actions[bot] · 3 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

thancyya · 3 months ago

Reviewing the suggested duplicates — none of these match our issue:

#65056 is the closest in mechanism (permission check skipped entirely), but the conditions are different: Bash tool on macOS in sandboxed mode with zero allow rules configured. Our case is PowerShell tool on Windows Desktop, non-sandboxed, with partial allow rules present in settings.local.json. These are likely different code paths.

#25181 was itself closed as a duplicate, macOS, Bash tool — not a match.

#63644 is a different problem category: Claude's model behavior choosing to run a destructive command autonomously. The permission gate may have been working as configured there. Our issue is specifically that the permission gate failed to fire at all for a command not covered by any allow rule.

Key differentiators for this issue:

PowerShell tool (not Bash) on Windows 11 Desktop (not macOS CLI)
Non-sandboxed, with some allow rules present — the permission system was active and prompting correctly for other commands in the same session
Transcript evidence: the session JSONL shows tool_use → tool_result with no permission event recorded between them — the prompt was not shown and not silently approved, it was never generated

BGMLAI · 3 months ago

PowerShell and cloud CLIs need to be part of the same permission event stream as Bash. If az ad group delete can execute without a prompt and without a transcript event, there are two independent failures: the action was not gated, and the audit trail cannot explain or reconstruct it.

I would normalize commands from every shell into a common action schema (provider, operation, target, destructive flag), then apply one policy floor before execution and record the decision regardless of shell.

Disclosure: I maintain gate.cat, an open-source pre-execution veto layer. Windows and cloud-CLI breadth is precisely why we favor normalized policies over a Bash-only list.

Showing cached comments. Read the full discussion on GitHub ↗