Summary

Describe the problem and fix in 2-5 bullets:

• Problem: macOS exec allowlist parsing treated combined POSIX shell -c forms such as bash -xc '<payload>' as direct shell executable invocations, so an allowlist entry for the shell could satisfy the guard while the inline payload was not evaluated.
• Why it matters: this weakens the operator's security: "allowlist" guarantee on the macOS Swift exec path and related node-host approval/allow-always binding paths.
• What changed: shared Swift and TypeScript inline-command parsing now recognizes combined POSIX -c forms, keeps payload parsing aligned across allowlist and system-run validation, and fails closed for startup/login/interactive/fish/env-modified shell wrappers that cannot be safely bound to an inner payload.
• What did NOT change (scope boundary): no unrelated UI, docs, CI, dependency, plugin, or model/provider behavior is changed; this PR is scoped to exec approval / shell-wrapper parsing and tests.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related https://github.com/NVIDIA-dev/openclaw-tracking/issues/567
• Related GHSA-c226-q6fx-6j6c
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

External contributors must show after-fix evidence from a real OpenClaw setup. Unit tests, mocks, lint, typechecks, snapshots, and CI are supplemental only. Screenshots are encouraged even for CLI, console, text, or log changes; terminal screenshots and copied live output count. Be mindful of private information like IP addresses, API keys, phone numbers, non-public endpoints, or other private details when providing evidence.

• Behavior or issue addressed: macOS Swift shell-wrapper parser now treats combined POSIX -c forms as wrappers and exposes the inline payload to allowlist resolution instead of matching only the shell executable.
• Real environment tested: local macOS machine with Xcode 26.4.1, Apple Swift 6.3.1, arm64.
• Exact steps or command run after this patch: compiled and ran a direct Swift parser harness against the actual base and head parser sources for [/bin/bash, -c, /usr/bin/printf safe_marker] and [/bin/bash, -xc, /usr/bin/printf safe_marker].
• Evidence after fix: copied terminal output from the macOS Swift harness:

  Base: baseline isWrapper=true command=/usr/bin/printf safe_marker
  Base: combined isWrapper=false command=nil
  Head: baseline isWrapper=true command=/usr/bin/printf safe_marker
  Head: combined isWrapper=true command=/usr/bin/printf safe_marker
  

• Observed result after fix: the combined POSIX -c form now resolves to /usr/bin/printf safe_marker, so allowlist evaluation sees the payload executable instead of matching only /bin/bash; unbindable startup/login/env-modified shell wrapper shapes fail closed rather than minting payload-only allowlist or approval entries.
• What was not tested: broad full-suite gates were not run locally; validation stayed focused on the changed exec approval and shell-wrapper surfaces.
• Before evidence (optional but encouraged): the base harness reproduced the reported behavior with combined isWrapper=false command=nil for /bin/bash -xc /usr/bin/printf safe_marker.

Root Cause (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

• Root cause: the macOS Swift shell-wrapper allowlist parser only recognized exact POSIX inline-command tokens such as -c / -lc, while valid combined short option forms containing c were treated as ordinary shell invocations.
• Missing detection / guardrail: allowlist and display/raw-command validation had separate inline-command parsing logic, allowing parser drift between execution validation and allowlist resolution.
• Contributing context (if known): payload-only allow-always and durable approval binding need stricter treatment for shell startup forms because login/interactive/fish/env-modified wrappers can execute wrapper-side startup code before the inline payload.

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should catch this. Otherwise write N/A.

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • apps/macos/Tests/OpenClawIPCTests/ExecAllowlistTests.swift
  • apps/macos/Tests/OpenClawIPCTests/ExecSystemRunCommandValidatorTests.swift
  • src/infra/shell-inline-command.test.ts
  • src/infra/exec-approvals-allow-always.test.ts
  • src/infra/system-run-command.test.ts
  • src/node-host/invoke-system-run-plan.test.ts
  • test/fixtures/system-run-command-contract.json
• Scenario the test should lock in: combined POSIX -c forms parse to the inline payload for allowlist resolution; startup/login/env-modified wrappers and positional carriers do not bypass allowlist/allow-always approval binding.
• Why this is the smallest reliable guardrail: it exercises the parser and allowlist binding seams directly on both Swift and TypeScript implementations without requiring a full host exec E2E run.
• Existing test that already covers this (if any): existing shell-wrapper tests covered exact -c / -lc; this PR adds combined-form and blocked-wrapper regressions.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

Exec allowlist mode is stricter for shell-wrapper commands. Combined POSIX -c forms are evaluated against their inline payloads, and unsafe startup/login/env-modified shell wrappers may require explicit approval instead of being satisfied by a shell executable or payload-only allow-always entry.

Diagram (if applicable)

Before:
[system.run bash -xc payload] -> [macOS allowlist resolves /bin/bash] -> [payload not checked]

After:
[system.run bash -xc payload] -> [parser extracts payload] -> [allowlist checks payload executable]

Blocked forms:
[startup/login/env-modified shell wrapper] -> [cannot bind payload safely] -> [approval/allowlist miss]

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: command execution approval and allowlist parsing is tightened. The compatibility risk is that previously accepted shell-wrapper shapes may now prompt or fail closed; mitigation is preserving safe generated legacy sh -lc raw-payload binding and adding focused Swift/TS regression coverage.

Repro + Verification

Environment

• OS: macOS on arm64
• Runtime/container: Xcode 26.4.1, Apple Swift 6.3.1, Node.js v22.22.2
• Model/provider: N/A
• Integration/channel (if any): macOS exec host / node-host system.run
• Relevant config (redacted): exec security: "allowlist"; allowlist includes a POSIX shell executable for the original bypass scenario.

Steps

1. Compile/run a direct Swift parser harness against base and head parser sources with [/bin/bash, -c, /usr/bin/printf safe_marker] and [/bin/bash, -xc, /usr/bin/printf safe_marker].
2. Run focused macOS Swift tests for ExecAllowlistTests and ExecSystemRunCommandValidatorTests.
3. Run focused TypeScript parser, allowlist, command analysis, node-host approval-plan, and system-run tests.
4. Run targeted typecheck, formatter check, whitespace check, and codex review --base origin/main.

Expected

• Exact -c and combined POSIX -c forms both expose the inline payload for allowlist evaluation.
• Unsafe startup/login/env-modified wrapper forms fail closed for payload-only allowlist/approval binding.

Actual

• Base parser reproduced the bug: combined form returned isWrapper=false command=nil.
• Head parser returns isWrapper=true command=/usr/bin/printf safe_marker for the combined form.
• Focused Swift and TypeScript checks passed.

Evidence

Attach at least one:

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

Human Verification (required)

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

• Verified scenarios: combined POSIX -c macOS parser behavior; Swift allowlist/system-run validator tests; TypeScript shell parser, allowlist/allow-always, command explainer/risk, system-run, and node-host approval-plan behavior; codex review --base origin/main.
• Edge cases checked: -xc, -ec, -euxc, -cx, options with separate values such as -O/-o, rawless sh -lc, legacy generated sh -lc raw-payload binding, env-modified shell wrappers, login/interactive wrappers, fish init/attached command forms, and positional carriers.
• What you did not verify: broad full-suite gates and live end-to-end execution through a production-installed OpenClaw gateway.

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.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes, with stricter approval prompts for unsafe shell-wrapper forms.
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: stricter shell-wrapper binding may cause additional approval prompts for commands that previously matched a broad shell allowlist entry.
  • Mitigation: preserve safe generated legacy sh -lc raw-payload binding and cover blocked forms with focused Swift/TS tests.
• Risk: Swift and TypeScript parser behavior could drift again.
  • Mitigation: shared contract fixture coverage plus mirrored parser tests on both implementations.