Bug type

Regression (worked before, now fails)

Summary

After upgrading to 2026.3.11, exec host=node from a macOS gateway to a paired Windows node fails with SYSTEM_RUN_DENIED: approval requires an existing canonical cwd. Three independent regressions compound to block the workflow entirely with no documented workaround.

Environment

• Gateway: macOS (Mac mini, arm64, no Docker sandbox)
• Node: Windows (headless node host, T-N2508, OpenClaw 2026.3.11)
• OpenClaw version: 2026.3.11
• Prior working version: 2026.3.8

Steps to reproduce

1. Pair a Windows headless node host to a macOS gateway.
2. Set tools.exec.host=node (as documented for node exec).
3. Call exec(host="node", node="T-N2508", workdir="C:\Windows\Temp", command='powershell -Command "echo ok"').
4. Observe failure.

Expected behavior

Command executes on the Windows node and returns ok.

Actual behavior

Three sequential failure modes, each exposed after working around the previous:

Regression 1 — tools.exec.host is now an exclusive policy with no multi-host option

File: reply-BCcP6j4h.js ~line 13601

if (!elevatedRequested && requestedHost && requestedHost !== configuredHost) throw new Error(...)

Setting tools.exec.host=node blocks all local gateway commands. Setting it to gateway blocks host=node calls. There is no config value that allows both hosts simultaneously. Before 2026.3.11 this appears to have been more permissive.

Workaround tested: Patch condition to !(configuredHost === "gateway" && requestedHost === "node").

Regression 2 — resolveWorkdir validates the workdir against the gateway's filesystem for host=node calls

File: reply-BCcP6j4h.js ~line 13623

} else workdir = resolveWorkdir(rawWorkdir, warnings);

resolveWorkdir calls statSync(workdir) on the Mac gateway. A Windows path like C:\Windows\Temp does not exist on the Mac filesystem, so resolveWorkdir silently falls back to the agent's Mac workspace path (/Users/.../workspace-opsos). That Mac path is then forwarded to the Windows node as cwd, which cannot canonicalize it → SYSTEM_RUN_DENIED: approval requires an existing canonical cwd.

This branch runs for both host=gateway and host=node. For node exec, the cwd should be forwarded raw and validated on the node.

Workaround tested: } else if (host !== "node") workdir = resolveWorkdir(rawWorkdir, warnings);

Regression 3 — Gateway sends approved: false to node even when security=full, ask=off

File: reply-BCcP6j4h.js ~line 13451

const raw = await callGatewayTool("node.invoke", ..., buildInvokeParams(false, null));

When requiresAsk=false (i.e., gateway config is security=full, ask=off), the gateway still passes approved: false to the Windows node via system.run. The Windows node then re-evaluates policy using its own local config (which defaults to security=allowlist, ask=on-miss via resolveExecSecurity(undefined) → "allowlist"). The command is denied with SYSTEM_RUN_DENIED: approval required.

The intent of the gateway's security=full config is lost in translation to the node.

Workaround tested: buildInvokeParams(hostSecurity === "full", null) — forwards approved: true when gateway security is full.

Note on intentionality

We recognize regressions 1 and 3 may be intentional security hardening. If so, the documentation and error messages need to reflect a supported path for cross-platform gateway→node exec. Currently there is no documented workaround that restores the previously working workflow.

Workaround status

All three patches applied locally to reply-BCcP6j4h.js and compact-1mmJ_KWL.js on the Mac gateway. Testing in progress. These patches will be lost on the next npm update.

Additional context

The system.run.prepare call correctly forwards cwd: params.workdir (line 13228), so the Windows node receives the correct path for plan building. The bug is that resolveWorkdir corrupts params.workdir before that line when the gateway filesystem cannot resolve the path.