[Repo Assist] fix(security): handle all PowerShell -EncodedCommand abbreviations and separator forms in ExecShellWrapperParser

[github-actions]

🤖 This is an automated PR from Repo Assist.

Problem

ExecShellWrapperParser.ParsePowerShellPayload only recognised three forms of the -EncodedCommand flag:

• -EncodedCommand (full name)
• -enc (short prefix)
• -ec (explicit alias)

PowerShell also accepts:

Form	Example
All unique prefix abbreviations	-en, -enco, -encod, -encode, -encoded, ...
Inline colon separator	-enc:PAYLOAD, -EncodedCommand:PAYLOAD
Inline equals separator	-enc=PAYLOAD, -EncodedCommand=PAYLOAD

Security impact

ExecShellWrapperParser is called in SystemCapability.HandleRunAsync (line 374) after the top-level command has already passed the exec approval policy. Its job is to expand shell wrappers so the inner commands are independently evaluated. If an unrecognised flag form is used (e.g. powershell -encode <b64>), the parser emits no targets and the encoded inner command is never checked against policy — while the outer powershell -encode <b64> command may pass as-is.

Fix

• Add IsEncodedCommandFlag helper: matches -ec (explicit alias) and all unique prefix abbreviations from the minimum disambiguation point (-en, 2 chars after -) up to the full flag name. -e alone is intentionally excluded as it is ambiguous with -ExecutionPolicy.
• Add IndexOfFlagSeparator to detect inline : / = separator forms (a single token containing both flag and value).
• Add IsCommandFlag helper for -Command / -c.
• Extract DecodeEncodedPayload helper to avoid duplicating the base-64 try/catch.
• Same separator handling added for -Command/-c as a bonus fix.

Tests

22 new tests added:

Category	Count
All 12 prefix abbreviations (-en through -encodedcommand)	12
Colon separator (-enc:, -EncodedCommand:, -encodedcommand:)	3
Equals separator (-enc=, -EncodedCommand=)	2
-Command: / -c: colon separator	2
-Command= / -c= equals separator	2
Ambiguous -e must NOT decode	1

Test Status

Suite	Before	After
OpenClaw.Shared.Tests	1172 pass / 2 fail† / 20 skip	1194 pass / 2 fail† / 20 skip
OpenClaw.Tray.Tests	406 pass / 1 fail‡ / 0 skip	406 pass / 1 fail‡ / 0 skip (unchanged)

† Pre-existing canvas JSONL failures on Linux (addressed by PR #264, not yet merged).
‡ Pre-existing DPAPI failure on non-Windows (addressed by PR #265, not yet merged).

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[shanselman]

Thanks for tightening the encoded-command handling here. I think this still needs one security-critical adjustment before it is safe to merge.

On Windows, powershell.exe -e <base64> is accepted as an alias for -EncodedCommand and executes the encoded payload. This PR intentionally excludes -e, so an allowlisted PowerShell invocation can still hide the actual command behind encoded content.

I also could not reproduce direct process acceptance for the colon/equals forms (-enc:<payload>, -enc=<payload>, -Command:..., -Command=...) in Windows PowerShell. Conservative rejection is fine, but the real blocker is that -e must be treated as encoded-command as well.