PowerShell safety guard false positive: here-string body text with paths like /requirements.txt blocked as 'Remove-Item on system path'

Summary

The PowerShell command safety analyzer produces a false positive that blocks legitimate commands: when a command passes a multiline single-quoted here-string (@'...'@) to an external CLI (e.g. gh pr create --body @'...'@), and the here-string text contains root-like paths (e.g. a Markdown list mentioning /app/config.py, /requirements.txt, /passenger_wsgi.py), the tool call is blocked with:

Remove-Item on system path '/requirements.txt,' is blocked. This path is protected from removal.

No Remove-Item/rm/del is present anywhere in the command. Note the trailing comma in the reported path — the analyzer appears to be tokenizing prose from inside the here-string literal instead of treating it as an opaque string argument.

Environment

• Claude Code on Windows 11 Pro (10.0.26200), PowerShell tool (pwsh 7+)
• Model: claude-fable-5
• No user-configured PreToolUse hooks (verified: only a SessionStart hook in settings)

Repro

gh pr create --base develop --title "x" --body @'
Verified today: `/app/config.py`, `/requirements.txt`, `/passenger_wsgi.py` return **403**.
'@

Also reproduced with gh issue comment <n> --body @'...'@ containing the same kind of path list. Same command with the identical text passed via --body-file <file> works fine (that is the workaround we now use).

Expected

The here-string is a single literal string argument; its contents should not be parsed as commands/paths by the protected-path guard.

Actual

The call is blocked before execution with the "Remove-Item on system path ... is blocked" message, with a path fragment (including punctuation from the surrounding prose) extracted from the string literal.