Recognize PowerShell -ec inline commands [AI] by pgondhi987 · Pull Request #80893 · openclaw/openclaw

pgondhi987 · 2026-05-12T05:24:20Z

Summary

Problem: PowerShell wrapper parsing did not classify the -ec encoded-command alias as an inline payload carrier.
Why it matters: system.run allowlist evaluation needs to inspect the payload instead of only the wrapper executable.
What changed: Added -ec to the PowerShell inline flag set and added regressions for parser extraction, wrapper extraction, command resolution, and allowlist handling.
What did NOT change (scope boundary): No behavior changes for non-PowerShell wrappers, config formats, manifests, or runtime dependencies.

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

N/A
This PR addresses a bug or regression

Real behavior proof (required for external PRs)

Behavior or issue addressed: PowerShell -ec wrapper invocations are classified as inline payload carriers before allowlist fallback.
Real environment tested: Not run in this branch by the AI assistant.
Exact steps or command run after this patch: Not run; supervisor requested metadata only and earlier work was constrained from running project commands.
Evidence after change: New regression coverage in src/infra/shell-inline-command.test.ts, src/infra/system-run-command.test.ts, src/infra/exec-wrapper-resolution.test.ts, and src/node-host/invoke-system-run.test.ts.
Observed result after change: Not runtime-verified by the AI assistant.
What was not tested: Full OpenClaw runtime, CI, and live PowerShell execution.
Before evidence (optional but encouraged): N/A

Root Cause (if applicable)

Root cause: The recognized PowerShell inline-command flag set omitted a valid encoded-command alias.
Missing detection / guardrail: Existing regressions covered -EncodedCommand and -enc, but not -ec.
Contributing context (if known): The allowlist path depends on shell payload extraction to select payload analysis instead of ordinary executable matching.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Unit test
- Seam / integration test
- End-to-end test
- Existing coverage already sufficient
Target test or file: src/infra/shell-inline-command.test.ts, src/infra/system-run-command.test.ts, src/infra/exec-wrapper-resolution.test.ts, src/node-host/invoke-system-run.test.ts
Scenario the test should lock in: pwsh -ec <payload> is extracted as a PowerShell inline payload and does not pass allowlist evaluation merely because the wrapper executable is allowlisted.
Why this is the smallest reliable guardrail: It covers the shared parser and the system.run allowlist decision without requiring PowerShell to be installed.
Existing test that already covers this (if any): N/A
If no new test is added, why not: N/A

User-visible / Behavior Changes

PowerShell -ec wrapper invocations are now treated consistently with other encoded-command aliases during system.run approval evaluation.

Diagram (if applicable)

Before:
[system.run argv] -> [PowerShell -ec not extracted] -> [wrapper executable allowlist path]

After:
[system.run argv] -> [PowerShell -ec payload extracted] -> [inline payload evaluation]

Security Impact (required)

New permissions/capabilities? (Yes/No) No
Secrets/tokens handling changed? (Yes/No) No
New/changed network calls? (Yes/No) No
Command/tool execution surface changed? (Yes/No) Yes
Data access scope changed? (Yes/No) No
If any Yes, explain risk + mitigation: PowerShell -ec invocations now take the stricter inline-payload approval path. This reduces unintended wrapper-only allowlist matching and does not add new command capabilities.

Repro + Verification

Environment

OS: Not runtime-tested by the AI assistant
Runtime/container: Not runtime-tested by the AI assistant
Model/provider: N/A
Integration/channel (if any): N/A
Relevant config (redacted): system.run allowlist mode with a PowerShell wrapper allowlist entry

Steps

Configure host exec approvals in allowlist mode with a PowerShell wrapper executable allowlisted.
Invoke system.run with a PowerShell -ec encoded payload.
Confirm the request follows inline payload evaluation rather than wrapper-only executable matching.

Expected

The encoded payload is extracted and evaluated as inline command content.

Actual

Not runtime-verified by the AI assistant.

Evidence

Failing test/log before + passing after
Trace/log snippets
Screenshot/recording
Perf numbers (if relevant)

Added regression coverage in the changed test files; project commands were not run by the AI assistant.

Human Verification (required)

What you personally verified (not just CI), and how:

Verified scenarios: Reviewed the parser flag table and added regressions for lowercase and uppercase -ec, command extraction, wrapper extraction, and allowlisted wrapper handling.
Edge cases checked: Case-insensitive PowerShell flag normalization.
What you did not verify: Full test suite, live OpenClaw runtime, and live PowerShell execution.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? (Yes/No) Yes
Config/env changes? (Yes/No) No
Migration needed? (Yes/No) No
If yes, exact upgrade steps: N/A

Risks and Mitigations

Risk: A previously allowlisted PowerShell wrapper invocation using -ec may now require inline payload approval.
- Mitigation: This matches existing handling for other encoded-command aliases and keeps approval behavior consistent.

clawsweeper · 2026-05-12T05:27:29Z

Codex review: needs real behavior proof before merge.

Summary
The PR expands PowerShell inline-command parsing for abbreviated/slash switch forms including -ec and adds parser, wrapper-resolution, command-display, and system.run allowlist regression tests.

Reproducibility: Do we have a high-confidence way to reproduce the issue? Yes from source and dependency proof: current main omits -ec from the PowerShell inline flag set, while PowerShell docs and local pwsh -ec execution confirm it is an encoded-command alias.

Real behavior proof
Needs real behavior proof before merge: Missing: the PR body says no real environment or live PowerShell/OpenClaw runtime command was run after the patch; the contributor should add redacted terminal/live-output or log proof and update the PR body for fresh ClawSweeper review.

Next step before merge
Protected maintainer label plus missing external real behavior proof make this a maintainer/contributor proof gate rather than a safe repair-automation task.

Security
Cleared: Cleared: the diff tightens an existing command-approval classifier and adds no dependencies, workflow changes, secret handling, network access, or new execution capability.

Review details

Best possible solution:

Have a maintainer review the security-sensitive approval behavior, require or explicitly override real behavior proof, and land the narrow parser/test change if the proof and required checks are acceptable.

Do we have a high-confidence way to reproduce the issue?

Do we have a high-confidence way to reproduce the issue? Yes from source and dependency proof: current main omits -ec from the PowerShell inline flag set, while PowerShell docs and local pwsh -ec execution confirm it is an encoded-command alias.

Is this the best way to solve the issue?

Is this the best way to solve the issue? Yes, extending the shared PowerShell parser and its downstream regression tests is the narrow maintainable fix; merge still needs maintainer handling because of proof and security-sensitive approval scope.

Acceptance criteria:

Review contributor-provided redacted real behavior proof for pwsh -ec through the changed system.run approval path.
If proceeding, run pnpm test src/infra/shell-inline-command.test.ts src/infra/system-run-command.test.ts src/infra/exec-wrapper-resolution.test.ts src/node-host/invoke-system-run.test.ts or the corresponding changed lane.

What I checked:

Live PR state: The GitHub issue API reports the PR open with labels maintainer and size: M; the protected maintainer label prevents cleanup closing.
Current main omits -ec: Current main's POWERSHELL_INLINE_COMMAND_FLAGS includes -encodedcommand, -enc, and -e, but not -ec. (src/infra/shell-inline-command.ts:4, 3b82156dff09)
Current parser depends on the flag set: resolveInlineCommandMatch lowercases the token and only extracts a payload when the supplied flag set contains that token, so -ec is missed on current main. (src/infra/shell-inline-command.ts:123, 3b82156dff09)
Allowlist path consumes the extracted shell payload: system.run passes parsed.shellPayload into allowlist evaluation, so missing PowerShell extraction can fall back to wrapper executable analysis. (src/node-host/invoke-system-run.ts:392, 3b82156dff09)
PowerShell contract supports -ec: Microsoft's about_Pwsh documentation lists -EncodedCommand | -e | -ec; local pwsh -ec <UTF-16LE base64> also printed the expected payload output.
PR diff reviewed: The head diff updates the shared PowerShell parser path and focused tests without changing dependencies, workflows, package resolution, secrets, network calls, or release scripts. (src/infra/shell-inline-command.ts:14, a9c289b60ec0)

Likely related people:

steipete: GitHub commit history shows steipete introduced PowerShell encoded-command recognition and later maintained the shell-inline and command-analysis paths. (role: recent area contributor and original encoded-command implementer; confidence: high; commits: 1d1757b16f48, 8fc53e7937c8, bd0e10a2f68f; files: src/infra/shell-inline-command.ts, src/infra/system-run-command.ts, src/node-host/invoke-system-run.ts)
pgondhi987: Beyond this PR, GitHub history shows pgondhi987 previously landed shell-wrapper allowlist parsing and shell-wrapper detection hardening in the same parser/runtime area. (role: prior merged area contributor; confidence: medium; commits: fc065b2693bf, 8f8492d172f4; files: src/infra/shell-inline-command.ts, src/infra/shell-wrapper-resolution.ts, src/infra/system-run-command.ts)

Remaining risk / open question:

The external contributor still has not provided after-fix real behavior proof; tests and CI are supplemental only.
The PR changes a security-sensitive command approval classifier and carries the protected maintainer label, so explicit maintainer handling is required before merge.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 3b82156dff09.

pgondhi987 · 2026-05-12T06:13:38Z

Not applicable to this automation stage; changelog/release-note and external real behavior proof requirements are handled outside auto-pr stages.

Quoted comment from @clawsweeper:

Codex review: needs real behavior proof before merge.

Summary
The PR expands PowerShell inline-command detection to abbreviated switch forms such as -ec and updates parser, wrapper-resolution, command-extraction, and system.run allowlist regression tests.

Reproducibility: Do we have a high-confidence way to reproduce the issue? Yes from source: current main does not include -ec in POWERSHELL_INLINE_COMMAND_FLAGS, while PowerShell 7.4.14 documents and executes -ec as an encoded-command alias.

Real behavior proof
Needs real behavior proof before merge: The PR body explicitly says no real environment, exact command, CI, full runtime, or live PowerShell execution was run after the patch; the contributor should add redacted terminal/log/live-output proof, then update the PR body for re-review or ask for @clawsweeper re-review.

Next step before merge
Maintainer handling is required because the PR is protected by the maintainer label and lacks external real behavior proof for a security-sensitive command approval path.

Security
Cleared: The diff tightens existing PowerShell encoded-command approval classification and does not add dependencies, network access, secret handling, or new execution capability.

Review details

Best possible solution:

Have a maintainer review the security-sensitive approval behavior, require or explicitly override real behavior proof, and then land the narrow parser/test change if CI is green.

Do we have a high-confidence way to reproduce the issue?

Do we have a high-confidence way to reproduce the issue? Yes from source: current main does not include -ec in POWERSHELL_INLINE_COMMAND_FLAGS, while PowerShell 7.4.14 documents and executes -ec as an encoded-command alias.

Is this the best way to solve the issue?

Is this the best way to solve the issue? Yes, the PR extends the existing shared PowerShell parser surface and adds focused regressions across the downstream paths that consume it.

What I checked:

Protected label: The live issue API and provided context show this open PR has the protected maintainer label, so this cleanup workflow should not close it automatically.

Current main lacks -ec recognition: Current main recognizes -encodedcommand, -enc, and -e in POWERSHELL_INLINE_COMMAND_FLAGS, but not -ec, so the central change is not already implemented. (src/infra/shell-inline-command.ts:4, 0eb50f9f8d00)

PowerShell contract supports the alias: Installed PowerShell 7.4.14 help documents -EncodedCommand | -e | -ec, and direct pwsh -ec <UTF-16LE base64> execution printed the expected payload output.

Current parser uses shared flag lookup: resolveInlineCommandMatch lowercases the token before checking the supplied flag set, so adding lowercase PowerShell aliases to the shared set is the existing parser extension point. (src/infra/shell-inline-command.ts:108, 0eb50f9f8d00)

Downstream allowlist behavior depends on extraction: extractShellCommandFromArgv delegates through shell-wrapper extraction, and existing system.run tests already deny pwsh -EncodedCommand in allowlist mode when only the wrapper executable is allowlisted. (src/infra/system-run-command.ts:56, 0eb50f9f8d00)

PR diff reviewed: The PR diff updates only parser/runtime helper code and focused tests; it does not change dependencies, workflows, package resolution, release scripts, secret handling, or network behavior. (src/infra/shell-inline-command.ts:1, 8d19dd421edf)

Likely related people:

steipete: GitHub commit history for the affected parser and command-analysis paths shows recent commits by steipete, including shell inline cleanup and inline-eval command-analysis routing. (role: recent area contributor; confidence: high; commits: 8fc53e7937c8, bd0e10a2f68f, 3f7e6eebc2f5; files: src/infra/shell-inline-command.ts, src/node-host/invoke-system-run.ts)

pgondhi987: GitHub commit history shows pgondhi987 authored merged shell-wrapper allowlist parsing work in the same parser and wrapper-resolution area before this PR, so they have current-main history beyond this proposed branch. (role: prior merged area contributor; confidence: medium; commits: fc065b2693bf; files: src/infra/shell-inline-command.ts, src/infra/shell-wrapper-resolution.ts)

Remaining risk / open question:

The PR changes security-sensitive command approval classification and has the protected maintainer label, so it needs explicit maintainer handling before merge.

The external contributor has not provided real after-fix runtime proof; tests alone do not satisfy the real behavior proof gate.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 0eb50f9f8d00.

* fix: recognize PowerShell -ec inline command flag * fix: recognize PowerShell -ec inline command flag * addressing codex review * addressing codex review * addressing codex review * addressing codex review * addressing codex review * fix: recognize PowerShell encoded command prefixes * addressing review-skill * addressing review-skill * addressing codex review * addressing codex review * docs: add changelog entry for PR merge

pgondhi987 added 2 commits May 12, 2026 03:40

fix: recognize PowerShell -ec inline command flag

b5ddedd

fix: recognize PowerShell -ec inline command flag

160904c

openclaw-barnacle Bot added size: XS maintainer Maintainer-authored PR labels May 12, 2026

addressing codex review

01116e8

openclaw-barnacle Bot added size: S and removed size: XS labels May 12, 2026

pgondhi987 added 2 commits May 12, 2026 05:36

addressing codex review

98427af

addressing codex review

6ec1699

openclaw-barnacle Bot added size: M and removed size: S labels May 12, 2026

pgondhi987 added 3 commits May 12, 2026 05:44

addressing codex review

8545d13

addressing codex review

8d19dd4

fix: recognize PowerShell encoded command prefixes

ce2ea8f

pgondhi987 added 6 commits May 12, 2026 06:15

addressing review-skill

6bc47f1

addressing review-skill

cbfebbb

addressing codex review

44cb6c4

addressing codex review

a9c289b

Merge remote-tracking branch 'origin/main' into fix/fix-588

88b678f

docs: add changelog entry for PR merge

1360dc9

pgondhi987 merged commit de47989 into openclaw:main May 12, 2026
21 of 22 checks passed

github-actions Bot mentioned this pull request May 12, 2026

📡 Upstream Digest — 2026-05-12 10:25 UTC curtismercier/openclaw-mods#837

Open

clawsweeper Bot mentioned this pull request May 12, 2026

Enforce inline shell wrapper payload matching [AI] #80978

Merged

25 tasks

clawsweeper Bot mentioned this pull request Jun 14, 2026

fix(exec): fail closed on Windows shell wrappers in allowlist mode #67655

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Recognize PowerShell -ec inline commands [AI]#80893

Recognize PowerShell -ec inline commands [AI]#80893
pgondhi987 merged 14 commits into
openclaw:mainfrom
pgondhi987:fix/fix-588

pgondhi987 commented May 12, 2026

Uh oh!

clawsweeper Bot commented May 12, 2026 •

edited

Loading

Uh oh!

pgondhi987 commented May 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

pgondhi987 commented May 12, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Real behavior proof (required for external PRs)

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

clawsweeper Bot commented May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pgondhi987 commented May 12, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented May 12, 2026 •

edited

Loading