feat(sparsekernel): run acceptance lanes and remote sandbox wrappers

Author: AceGreenman

docs/architecture/browser-broker.md

@@ -29,4 +29,4 @@ Use `openclaw sparsekernel browser-targets` and `openclaw sparsekernel browser-o
 
 BrowserContext isolation is session isolation, not host isolation. Playwright route blocking is useful request control, not a hard security boundary.
 
-The brokered CDP action engine is intentionally implemented inside the broker boundary, but it is not a byte-for-byte Playwright clone. Behaviors that depend on Playwright's complete locator model, every actionability edge case, popup ownership, or network-idle semantics should still be covered by targeted tests before relying on them for critical automations. Set `OPENCLAW_SPARSEKERNEL_BROWSER_LIVE=1` when running `src/local-kernel/browser-cdp-live.test.ts` to exercise the native pool and brokered actions against a real local Chromium-compatible browser.
+The brokered CDP action engine is intentionally implemented inside the broker boundary and covered by the `browser-cdp` acceptance lane. Behaviors that depend on browser action semantics should be added to that lane before being treated as supported automation contract. Set `OPENCLAW_SPARSEKERNEL_BROWSER_LIVE=1` when running `src/local-kernel/browser-cdp-live.test.ts` to exercise the native pool and brokered actions against a real local Chromium-compatible browser.

docs/architecture/local-agent-kernel.md

@@ -161,14 +161,14 @@ Run:
 openclaw runtime doctor
 ```
 
-The doctor reports schema status, session-store mode, transcript compatibility mode, ToolBroker mode, sandbox backend availability, small-VM resource budgets, hard-egress configuration, loopback proxy configuration, managed worker identity status, plugin subprocess readiness, browser broker status, and the SparseKernel acceptance lanes. `openclaw runtime acceptance --strict --current-platform` turns those readiness checks into a fail-closed operator gate for ledger-only transcripts, brokered tools, plugin subprocess policy, explicit browser brokering, egress proxy setup, and resource-budget availability. `openclaw runtime cutover-plan` prints the import, environment, acceptance, and JSONL export commands for a staged strict cutover. `pnpm sparsekernel:acceptance` prints the cross-platform lane map for local or CI orchestration.
+The doctor reports schema status, session-store mode, transcript compatibility mode, ToolBroker mode, sandbox backend availability, small-VM resource budgets, hard-egress configuration, loopback proxy configuration, managed worker identity status, plugin subprocess readiness, browser broker status, and the SparseKernel acceptance lanes. `openclaw runtime acceptance --strict --current-platform` turns those readiness checks into a fail-closed operator gate for ledger-only transcripts, brokered tools, plugin subprocess policy, explicit browser brokering, egress proxy setup, and resource-budget availability. Add `--run` to execute the required lanes from the same command, and add `--include-recommended` to include browser and platform hard-egress conformance lanes. `openclaw runtime cutover-plan` prints the import, environment, executable acceptance, and JSONL export commands for a staged strict cutover. `pnpm sparsekernel:acceptance --run --include-recommended` runs the same lane map without opening the runtime ledger.
 
 ## Current limitations
 
 - Full transcript ownership is still staged for default compatibility runs: session metadata can run with SQLite as primary, assistant delivery transcript appends can run ledger-only in strict mode, import/export is ledger-backed, and remaining pi session manager append paths now mirror through the runtime ledger append API before returning in primary modes. `OPENCLAW_SPARSEKERNEL_STRICT=1` selects the ledger-authoritative path for SparseKernel runs unless more specific session-store environment overrides are set. Legacy JSONL remains supported for compatibility and export, but strict ledger-only transcript appends no longer create a JSONL line unless compatibility mode is requested.
-- Native browser process pooling exists for loopback CDP contexts, but it is still a small supervisor around Chromium. Brokered actions now cover selector retry, same-origin frame-scoped actions, stronger actionability checks, CDP-backed network-idle waits, history back/forward, post-action navigation checks, click/coordinate-click/press modifiers, check/uncheck, console/screenshot/PDF/upload/dialog/download routes, staged artifact import/export, richer download observations, and per-pool context caps, but the engine is still not a full Playwright-equivalent process manager and does not provide host isolation.
-- Sandbox allocation can execute trusted local commands, hardened bwrap/minijail profile-wrapped commands when available, and policy-backed explicitly imaged Docker commands. `plugin_untrusted` rejects explicit `local/no_isolation` by default and auto-selects an available isolated backend when no backend is requested; `local/no_isolation` still does not harden trusted execution; Docker isolation depends on the host Docker daemon and selected image; VM wrappers are not implemented yet.
-- Bundled/native plugins still execute in process by default when no subprocess policy or operator default worker is configured. Non-bundled plugins are subprocess-first by default and fail closed without worker metadata or an operator default worker. Automatically extracting arbitrary existing plugin tool functions into a worker is still future work.
+- Native browser process pooling exists for loopback CDP contexts, but it is still a broker-owned Chromium supervisor rather than an exposed Playwright handle. Brokered actions now cover selector retry, same-origin frame-scoped actions through the proxy, stronger actionability checks, CDP-backed network-idle waits, history back/forward, post-action navigation checks, click/coordinate-click/press modifiers, check/uncheck, console/screenshot/PDF/upload/dialog/download routes, staged artifact import/export, richer download observations, and per-pool context caps. Browser conformance is an executable recommended acceptance lane; host isolation still comes from the browser process/sandbox boundary, not BrowserContext.
+- Sandbox allocation can execute trusted local commands, hardened bwrap/minijail profile-wrapped commands when available, policy-backed explicitly imaged Docker commands, and operator-supplied `vm`, `ssh`, `openshell`, or `other` command wrappers. VM/remote wrappers receive a `openclaw.sparsekernel.sandbox-command.v1` request plus the original command and stdin. `plugin_untrusted` rejects explicit `local/no_isolation` by default and auto-selects an available isolated backend, including a configured VM wrapper, when no backend is requested; `local/no_isolation` still does not harden trusted execution; Docker isolation depends on the host Docker daemon and selected image; remote wrapper isolation is only as strong as the operator-provided backend.
+- `OPENCLAW_SPARSEKERNEL_STRICT=1` now implies strict subprocess policy for all plugin tools, including bundled/native plugin tools. Tools with subprocess metadata or an operator default worker run through the sandbox broker; tools without either fail closed instead of silently falling back in process. Automatically extracting arbitrary existing plugin tool functions into a worker is still future work.
 - Network policy enforcement currently exists where brokers call it. DNS-aware denial is implemented for brokered browser navigation checks, proxy-required sandbox mode gates allocations and configures Docker/local proxy environment, and hard-egress sandbox mode can use the built-in no-network backend verifier for bwrap/Docker, the built-in scoped firewall manager for broker-managed UID/GID workers on Linux/macOS, Windows scoped allow rules after active default-block profile verification, or an external host firewall, egress proxy, VM firewall, or platform enforcer helper. SparseKernel still rejects unscoped arbitrary host-process firewall claims instead of treating them as a portable security boundary.
 
 ## Contributor rules

docs/architecture/security-boundaries.md

@@ -24,10 +24,11 @@ SparseKernel security claims must be precise.
 - `OPENCLAW_RUNTIME_SANDBOX_REQUIRE_HARD_EGRESS=1` fails closed for network-allowing sandbox trust zones unless `OPENCLAW_RUNTIME_SANDBOX_HARD_EGRESS_HELPER` confirms an allocation with a supported boundary: `host_firewall`, `egress_proxy`, `vm_firewall`, or `platform_enforcer`. Set the helper to `builtin` only when the selected backend itself carries the boundary SparseKernel knows how to verify, currently bwrap and Docker no-network plans in the local command runner. Set it to `builtin-firewall` for the built-in scoped host firewall manager. That manager can select a broker-managed local worker identity from `OPENCLAW_RUNTIME_SANDBOX_WORKER_IDENTITIES` or `OPENCLAW_RUNTIME_SANDBOX_WORKER_UIDS` and launch commands with Node's `uid`/`gid` spawn options, so operators no longer need to run the whole broker as the firewall-scoped user. `openclaw runtime worker-identities` generates the platform-specific provisioning plan and environment JSON for those accounts. Without a managed pool it still requires an explicit dedicated `uid:<id>`, `gid:<id>`, `sid:<sid>`, or `program:<path>` scope plus `OPENCLAW_RUNTIME_SANDBOX_FIREWALL_SCOPE_DEDICATED=1`. The built-in manager supports Linux iptables owner-match rules, macOS pf user/group anchors under the default `com.apple/*` anchor point, and Windows Firewall allow rules after it actively verifies enabled profiles with `DefaultOutboundAction Block`. It requires a loopback `proxy_ref` or IP/CIDR `allowed_hosts`, explicitly opts into host mutation with `OPENCLAW_RUNTIME_SANDBOX_FIREWALL_APPLY=1`, rejects shared OS users, unscoped arbitrary host processes, and unsafe Windows default-allow profiles instead of claiming a hard boundary, and records whether the firewall plan covers `all_ip` or only `tcp_udp`. Hostname allowlists are permitted only with a loopback proxy path; the firewall admits loopback traffic and the proxy path owns hostname enforcement. Set `OPENCLAW_RUNTIME_SANDBOX_FIREWALL_REQUIRE_FULL_PROTOCOL=1` to make TCP/UDP-only macOS pf plans fail closed. External helpers receive a JSON request on stdin for allocate/release and are operator-supplied privileged boundaries. SparseKernel records the helper result on the sandbox lease and audits enforcement, but the security property is only as strong as that backend or helper and the host policy it installs.
 - Browser proxy-required mode configures SparseKernel-owned native browser processes with a loopback proxy and denies unverified external CDP endpoints; it does not control arbitrary host processes.
 - Docker command execution requires an explicit image and disables container networking by default, but its isolation is only the host Docker daemon's isolation; it is not a per-agent security model.
+- VM, SSH, OpenShell, and custom sandbox backends are brokered through operator-supplied command wrappers. SparseKernel passes a `openclaw.sparsekernel.sandbox-command.v1` request and audits the lease, command, and result; the isolation property belongs to the operator backend. SSH transport by itself is not a sandbox boundary.
 - Persisted lease metadata records the selected backend and policy intent; it is audit/accounting state, not isolation by itself.
 - Untrusted plugins must not get ambient host authority.
 - The subprocess-required plugin mode runs explicit JSON workers through the sandbox broker. Use the standard SparseKernel plugin worker harness for the stdin/stdout protocol. The broker auto-selects an available isolated backend when possible, but it still only becomes suitable for untrusted code when the selected backend is a real isolation backend; `local/no_isolation` is blocked by default for plugin subprocess workers and should only be enabled for trusted local workers.
-- Plugin tool `processBoundary: "subprocess_required"` and `OPENCLAW_RUNTIME_PLUGIN_TRUST_DEFAULT=untrusted` are fail-closed controls for brokered tool execution; they do not make existing in-process plugin initialization safe.
+- Plugin tool `processBoundary: "subprocess_required"`, `OPENCLAW_RUNTIME_PLUGIN_TRUST_DEFAULT=untrusted`, and `OPENCLAW_SPARSEKERNEL_STRICT=1` are fail-closed controls for brokered tool execution; they do not make existing in-process plugin initialization safe.
 - Secrets should be referenced, not stored as plaintext in SQLite.
 
 Capabilities are the v0 policy primitive. They are intentionally simple: subject, resource, action, optional constraints, optional expiry. Denied sensitive checks are audit-logged.

docs/architecture/sparsekernel.md

@@ -56,4 +56,4 @@ The tool broker records tool-call lifecycle transitions, capability-checks agent
 
 ## Current limitations
 
-V0 proves the foundation. It does not implement every production sandbox backend, make subprocess plugin workers safe when no real isolation backend is available, provide full Playwright parity, or rewrite OpenClaw around SparseKernel. Hard sandbox egress can use the built-in no-network backend verifier for bwrap and Docker no-network plans in the local command runner, the built-in scoped firewall manager for broker-managed UID/GID workers on Linux/macOS, Windows scoped allow rules after active default-block profile verification, or an operator helper that installs and releases a real host firewall, egress proxy, VM firewall, or platform enforcement rule for each lease. SparseKernel now provides a daemon-owned built-in HTTP/CONNECT egress proxy lifecycle, `openclaw runtime worker-identities` to generate managed worker account provisioning plans, delegates hostname allowlists to configured loopback proxies instead of raw firewall rules, and records firewall protocol coverage in lease metadata. It still rejects unscoped arbitrary host-process firewall claims instead of treating them as a portable boundary.
+V0 proves the foundation. It does not rewrite all OpenClaw runtime behavior in one pass or turn broker accounting into a universal host security boundary. Hard sandbox egress can use the built-in no-network backend verifier for bwrap and Docker no-network plans in the local command runner, the built-in scoped firewall manager for broker-managed UID/GID workers on Linux/macOS, Windows scoped allow rules after active default-block profile verification, or an operator helper that installs and releases a real host firewall, egress proxy, VM firewall, or platform enforcement rule for each lease. SparseKernel now provides executable strict acceptance lanes, a daemon-owned built-in HTTP/CONNECT egress proxy lifecycle, brokered VM/remote sandbox wrapper commands, `OPENCLAW_SPARSEKERNEL_STRICT=1` as an all-plugin subprocess boundary, `openclaw runtime worker-identities` to generate managed worker account provisioning plans, hostname allowlists delegated to configured loopback proxies instead of raw firewall rules, and firewall protocol coverage in lease metadata. It still rejects unscoped arbitrary host-process firewall claims instead of treating them as a portable boundary.