PowerShell support: parser, hard-deny rules, safe-verb list, verb-chain extraction

[Aaronontheweb]

Summary

Approval gates today only understand Bash. To deploy Netclaw on Windows with pwsh/powershell as the operator's primary shell — or on a POSIX system where the operator prefers PowerShell — we need a parallel set of components that understand PowerShell command syntax. Bolting PowerShell awareness onto the existing Bash-shaped pipeline produces wrong matches on hard-deny, wrong verb-chain extraction, and wrong safe-verb auto-approvals.

Depends on

• Detect operator's active shell instead of assuming Bash #964 (detect operator's active shell instead of assuming Bash) — must land first so we know when to route through the PowerShell pipeline vs the Bash pipeline.

Components needed

1. PowerShellParser in ShellSyntaxTree (or a sibling library) producing the same ParsedCommand / Clause / Arg shape as BashParser, but parsed against PowerShell grammar (commands, parameter binding, pipeline operator |, statement separator ;, subexpression $(...), splatting, verb-noun cmdlet naming convention, etc.).

2. PowerShell-flavored safe-verb list at src/Netclaw.Configuration/Resources/safe-verbs.windows-pwsh.json (or similar). Read-only PowerShell cmdlets follow Verb-Noun convention with verbs from a closed set: Get-*, Find-*, Test-*, Resolve-*, Measure-*, etc. The auto-pass list should cover the common diagnostic surface (Get-ChildItem, Get-Content, Get-Process, Get-Service, Test-Path, Test-Connection, Resolve-DnsName, Measure-Object).

3. PowerShell-flavored hard-deny rules at src/Netclaw.Configuration/Resources/hard-deny.windows-pwsh.json. The Bash list (rm -rf /, dd if=, fork bombs) doesn't cover PowerShell equivalents: Remove-Item -Recurse -Force C:\\, Format-Volume, Stop-Computer -Force, Set-ExecutionPolicy Bypass, Invoke-Expression $env:DANGER, Invoke-WebRequest ... | Invoke-Expression, etc.

4. PowerShell verb-chain extraction — analogue of the BashParser's greedy verb extraction. PowerShell commands ARE verb-chains by design (Get-ChildItem, New-Item), so the extraction is simpler than Bash but the matcher needs to know that Get-ChildItem -Recurse C:\\foo matches the saved pattern Get-ChildItem *.

5. ToolAccessPolicy routing — given the detected shell from Detect operator's active shell instead of assuming Bash #964, dispatch the parsed command to the right policy chain (Bash hard-deny + safe-verbs vs PowerShell hard-deny + safe-verbs).

Why bother

• Windows operator deployments today either disable shell tooling entirely or run in WSL Bash. Neither is great.
• PowerShell on POSIX (pwsh) is increasingly the default for ops-heavy teams. We're not just talking about Windows.
• The current Bash-only assumption silently mis-applies hard-deny rules on non-Bash commands — that's a security gap, not just a UX gap.

Out of scope

• cmd.exe support. Cmd is its own beast and most operators have moved off it; YAGNI for v1.
• Per-clause shell switching (e.g., bash -c '...' inside a PowerShell pipeline). Treat at the outer-shell level.

[Aaronontheweb]

Scope clarification (per Aaron): netclaw will only ever support Bash and PowerShell as first-class shells. This issue covers the PowerShell half; the Bash half is what we already have. No cmd, no fish, no zsh-specific handling.

[Aaronontheweb]

PR #1733 adds the PowerShell parser, policy, approval, and execution path for Windows.

Netclaw uses PowerShell 7 on Windows and Bash on Unix. PowerShell on POSIX is not part of this platform contract.

The approval policy and the executor must use one deterministic interpreter. This rule prevents a parser and execution mismatch.

A future explicit shell option would need one parser, policy, and executor contract. It should use a separate issue.