PowerShell script blocks / subexpressions still bypass allowlist and prompt (re-file of #52926, stale-bot closed)

Summary

Re-filing #52926, which was closed today (2026-07-06) by the stale-issue bot ("Closing for now — inactive for too long") — not by a fix. The bug it describes is still reproducible and actively causing friction; the closing comment even landed the same day as multiple fleet telemetry reports confirming it's still the dominant source of manual approval prompts on Windows.

Original issue: #52926
Original summary: PowerShell(*) (and scoped cmdlet prefix rules like PowerShell(Get-ChildItem *)) do not cover commands containing subexpressions $(), script blocks { }, or variable interpolation — every such command still triggers a manual approval prompt ("Command contains subexpressions $()" / "Command contains script block that may execute arbitrary code"), regardless of allowlist coverage.

Why this needs to stay open

The original issue's own comment thread (through June 2026) shows the bug is unresolved:

• A scoped-prefix variant (PowerShell(Get-ChildItem *) never matching at all, even for zero-subexpression commands) reported on v2.1.160.
• A report of "Allow always" generating unusable, non-generalizing exact-string allowlist entries.
• A report of the resulting permission-prompt churn causing concurrent writes to settings.local.json that silently dropped a PreToolUse safety hook, leading to a production incident (repeated OOM kills from an unblocked script).

We independently confirmed this is still live via July 2026 fleet telemetry across ~320 Windows users of Claude Code (script-block and subexpression prompts remain one of the top hardcoded friction sources; workarounds like parameter-form Where-Object/ForEach-Object -MemberName substitutions are needed as a stopgap and are documented in our internal Windows usage guidelines).

Environment

• OS: Windows
• Claude Code: confirmed present through at least v2.1.168 (per #52926 thread and our own telemetry)

Request

Please reopen #52926 or track this as a live issue — the stale-bot closure does not reflect an actual fix, and closing it removes visibility into a bug that is currently the dominant PowerShell approval-friction source for Windows users.