Harden sandbox run security boundaries

[chubes4]

Gap

The current WordPress plugin runner shells out to the local CLI and accepts low-level inputs. That is fine for prototype/operator use, but not enough for frontend or hosted-product use.

Goal

Harden sandbox execution so chat/frontend users can request coding tasks without gaining host shell, arbitrary path, or parent-site mutation access.

Acceptance direction

• Restrict executable path to configured allow-list.
• Restrict component paths and artifact paths to configured allow-lists.
• Add task timeouts, process cleanup, concurrency limits, and quotas.
• Remove/lock down arbitrary code input from frontend-facing task APIs.
• Add audit logging for sandbox run requests and results.
• Add structured denial errors for path, command, quota, timeout, and permission failures.
• Ensure artifacts do not contain secrets.

Notes

This is prerequisite work before exposing sandbox runs to untrusted frontend users.

[chubes4]

Status after PRs #56-#59:\n\nSome safety boundary work landed as prerequisites:\n\n- run-agent-task rejects raw code/code_file at the parent-site ability layer (#56).\n- apply-approved-artifact validates approved_files against changed-files.json and reads the exact canonical patch.diff (#58).\n- artifact listing/discard is constrained to the configured artifact root (#58).\n\nKeeping this open for the deeper hardening scope:\n\n- real network/filesystem enforcement beyond schema validation\n- artifact redaction and secret scanning\n- stronger provenance verification/content-addressed IDs\n- apply adapter policy gates and secondary-review options\n- raw/operator ability separation if/when an operator WP ability is introduced