Summary
Standardize OpenClaw's core command-execution wrapper on Execa while preserving OpenClaw-specific process behavior.
Problem to solve
The current process layer manually coordinates child spawn, timeout, cancellation, output capture, and inherited-pipe cleanup. Several production call sites bypass that wrapper and reimplement parts of the same lifecycle, creating inconsistent timeout, environment, and Windows behavior.
Proposed solution
- Add a pinned Execa root runtime dependency with explicit dependency ownership.
- Rebuild the core exec layer on Execa for process lifecycle, cancellation, and output handling.
- Preserve bounded tail capture, selected-line preservation, no-output timeouts, process-tree termination, Windows console-codepage decoding, and safe batch-command handling for CVE-2024-27980.
- Replace the separate agent child-process waiter with one bounded inherited-pipe release helper.
- Migrate a first bounded set of production bypass sites; follow up on remaining raw child-process call sites by owner surface.
Alternatives considered
Keeping the hand-rolled lifecycle code leaves duplicated race handling and inconsistent call-site behavior. Replacing every raw spawn site in one change would make the first dependency migration unnecessarily difficult to review and validate.
Impact
Internal refactor. Public command behavior and plugin SDK exports should remain unchanged. The initial change should include focused process and agent-session tests, build/type proof, dependency lockfile checks, and Windows-specific coverage.
Evidence / examples
Primary surfaces: src/process/exec.ts, the agent child-process waiter, and raw spawn users in agent session tools.
Summary
Standardize OpenClaw's core command-execution wrapper on Execa while preserving OpenClaw-specific process behavior.
Problem to solve
The current process layer manually coordinates child spawn, timeout, cancellation, output capture, and inherited-pipe cleanup. Several production call sites bypass that wrapper and reimplement parts of the same lifecycle, creating inconsistent timeout, environment, and Windows behavior.
Proposed solution
Alternatives considered
Keeping the hand-rolled lifecycle code leaves duplicated race handling and inconsistent call-site behavior. Replacing every raw spawn site in one change would make the first dependency migration unnecessarily difficult to review and validate.
Impact
Internal refactor. Public command behavior and plugin SDK exports should remain unchanged. The initial change should include focused process and agent-session tests, build/type proof, dependency lockfile checks, and Windows-specific coverage.
Evidence / examples
Primary surfaces:
src/process/exec.ts, the agent child-process waiter, and raw spawn users in agent session tools.