Summary
Agent exec tool calls always execute on the gateway (arm64 / 10.0.0.191), never on the bound remote node — even when /exec session overrides explicitly specify host=node with the exact nodeId. CLI openclaw nodes run correctly routes to the node and the /bin/sh -lc wrapper works fine via CLI. The bug is isolated to the agent exec tool routing path.
Steps to reproduce
1 Pair and connect a remote node (openclaw nodes status shows paired/connected with system capability)
In an agent's Discord channel, start fresh:
2 /new
3 /verbose full
4 /exec host=node node= security=full ask=off
5 Send: "Use the exec tool to run: uname -m; ipconfig getifaddr en0 and reply with only stdout."
6 Observe tool bubble fires but output shows gateway arch/IP, not the node's
Expected behavior
When /exec host=node node= is set and the target node is paired, connected, and advertises system.run, agent exec tool calls should execute on that remote node — returning the node's architecture (x86_64), IP (10.0.0.200), and macOS Monterey 12.7.6 environment, not the gateway's (arm64 / 10.0.0.191 / macOS Sequoia).
Actual behavior
After /new (fresh session 5cfafdcf-7e36-4bcc-887a-462e11a2aa85), /verbose full, and /exec host=node node=1a0f052a6a0c494f8190d06c27735bcb89319d3ff73a6deae005e0f3f4bedd30 security=full ask=off, the exec tool fires (tool bubble visible) but returns arm64 / 10.0.0.191 — the gateway, not the bound node (x86_64 / 10.0.0.200). Reproduced on a completely fresh session with exact nodeId binding. openclaw nodes run --node correctly returns x86_64 / 10.0.0.200.
Additionally, when /elevated off is set to remove potential gateway forcing, exec fails with spawn /bin/sh ENOENT — despite /bin/sh existing on the node and the /bin/sh -lc wrapper working via nodes run.
OpenClaw version
2026.2.14
Operating system
mac os 12.7.6 (nodes) and macOS sequoia (gateway)
Install method
curl -fsSL https://openclaw.ai/install.sh | bash, npm (nodes)
Logs, screenshots, and evidence
Environment
OpenClaw Version: 2026.2.14 (c1feda1)
Install method: npm
Gateway: Apple Silicon Mac mini, macOS Sequoia, 10.0.0.191
Remote nodes: 2x 2014 Intel Mac minis, macOS Monterey 12.7.6 (paired, connected, system.run capability advertised)
Node "Tinker": 10.0.0.181, nodeId b54ce34e5236e704095c33e85369cd87b946e92f6d924a17d79304a496afec65
Node "Vault": 10.0.0.200, nodeId 1a0f052a6a0c494f8190d06c27735bcb89319d3ff73a6deae005e0f3f4bedd30
OpenClaw version on all three machines: 2026.2.14
Evidence
1. Session overrides correctly set
/exec host=node node=1a0f052a6a0c494f8190d06c27735bcb89319d3ff73a6deae005e0f3f4bedd30 security=full ask=off
/exec output confirms:
Current exec defaults: host=node, security=full, ask=off, node=Vault.
2. Exec tool fires but runs on gateway (not node)
With /verbose full enabled, tool bubble visible (🛠️ Exec: uname -m; ipconfig getifaddr en0), output:
arm64
10.0.0.191
arm64 = Apple Silicon gateway (should be x86_64 for 2014 Intel mini)
10.0.0.191 = gateway IP (should be 10.0.0.200 for Vault node)
3. Control: nodes run reaches the correct node (all three probes pass)
bash# Probe 1: Direct argv mode
$ openclaw nodes run --node Vault -- /usr/bin/uname -m
x86_64
# Probe 2: /bin/sh -lc wrapper (same wrapper exec host=node uses)
$ openclaw nodes run --node Vault -- /bin/sh -lc 'uname -m; ipconfig getifaddr en0'
x86_64
10.0.0.200
# Probe 3: /bin/sh exists on node
$ openclaw nodes run --node Vault -- ls -la /bin/sh
-rwxr-xr-x 1 root wheel 150384 Jul 17 2024 /bin/sh
Node is reachable, /bin/sh exists, the shell wrapper works via CLI. The issue is isolated to the agent exec tool routing path.
4. Node is connected and advertises system.run
$ openclaw nodes status
Known: 2 · Paired: 2 · Connected: 2
Node: Vault
ID: 1a0f052a6a0c494f8190d06c27735bcb89319d3ff73a6deae005e0f3f4bedd30
IP: 10.0.0.200
Caps: browser, system
Status: paired · connected
5. Elevated off causes spawn /bin/sh ENOENT
When /elevated off is set in the session, exec fails:
spawn /bin/sh ENOENT
This creates a catch-22: elevated mode forces exec to the gateway, but without elevated mode, the exec-to-node path fails with ENOENT — even though /bin/sh exists on the node and nodes run with the /bin/sh -lc wrapper works fine.
Impact and severity
Impact and Severity
-
Affected users: Any multi-node OpenClaw deployment attempting to distribute agent exec across remote nodes
-
Severity: Blocks workflow. Remote nodes cannot be used for agent exec, defeating the primary use case of a multi-node setup. All compute is forced onto the gateway regardless of config.
-
Frequency: Always. 100% reproducible across fresh sessions, multiple agents, display name and exact nodeId binding, per-agent config, global config, and session overrides. No combination of settings routes agent exec to a remote node.
-
Consequence: Remote nodes sit idle despite being paired, connected, and advertising system.run. Users must mount all shared resources (NAS, drives, etc.) on the gateway instead of on dedicated nodes. No workload distribution is possible. For setups where the gateway is a VPS or resource-constrained device, agents cannot leverage more capable local hardware. Additionally, attempting per-agent tools.exec.host/node config keys can cause spawn /bin/sh ENOENT errors that break agent exec entirely, requiring config removal and gateway restart to recover.
Additional information
Other Approaches Tried (all failed)
Approach | Result
-- | --
Per-agent agents.list[N].tools.exec.host=node + tools.exec.node=Vault | No effect on routing; also caused spawn /bin/sh ENOENT on another agent
Global tools.exec.host=node | No effect on routing
Top-level execNode on agent definition | Rejected by config validator: Unrecognized key: "execNode"
/exec host=node node=Vault (display name) | Exec runs on gateway
/exec host=node node= | Exec runs on gateway
/elevated off + /exec host=node node= | spawn /bin/sh ENOENT
Summary
Agent exec tool calls always execute on the gateway (arm64 / 10.0.0.191), never on the bound remote node — even when /exec session overrides explicitly specify host=node with the exact nodeId. CLI openclaw nodes run correctly routes to the node and the /bin/sh -lc wrapper works fine via CLI. The bug is isolated to the agent exec tool routing path.
Steps to reproduce
1 Pair and connect a remote node (openclaw nodes status shows paired/connected with system capability)
In an agent's Discord channel, start fresh:
2 /new
3 /verbose full
4 /exec host=node node= security=full ask=off
5 Send: "Use the exec tool to run: uname -m; ipconfig getifaddr en0 and reply with only stdout."
6 Observe tool bubble fires but output shows gateway arch/IP, not the node's
Expected behavior
When /exec host=node node= is set and the target node is paired, connected, and advertises system.run, agent exec tool calls should execute on that remote node — returning the node's architecture (x86_64), IP (10.0.0.200), and macOS Monterey 12.7.6 environment, not the gateway's (arm64 / 10.0.0.191 / macOS Sequoia).
Actual behavior
After /new (fresh session 5cfafdcf-7e36-4bcc-887a-462e11a2aa85), /verbose full, and /exec host=node node=1a0f052a6a0c494f8190d06c27735bcb89319d3ff73a6deae005e0f3f4bedd30 security=full ask=off, the exec tool fires (tool bubble visible) but returns arm64 / 10.0.0.191 — the gateway, not the bound node (x86_64 / 10.0.0.200). Reproduced on a completely fresh session with exact nodeId binding. openclaw nodes run --node correctly returns x86_64 / 10.0.0.200.
Additionally, when /elevated off is set to remove potential gateway forcing, exec fails with spawn /bin/sh ENOENT — despite /bin/sh existing on the node and the /bin/sh -lc wrapper working via nodes run.
OpenClaw version
2026.2.14
Operating system
mac os 12.7.6 (nodes) and macOS sequoia (gateway)
Install method
curl -fsSL https://openclaw.ai/install.sh | bash, npm (nodes)
Logs, screenshots, and evidence
Impact and severity
Impact and Severity
Affected users: Any multi-node OpenClaw deployment attempting to distribute agent exec across remote nodes
Severity: Blocks workflow. Remote nodes cannot be used for agent exec, defeating the primary use case of a multi-node setup. All compute is forced onto the gateway regardless of config.
Frequency: Always. 100% reproducible across fresh sessions, multiple agents, display name and exact nodeId binding, per-agent config, global config, and session overrides. No combination of settings routes agent exec to a remote node.
Consequence: Remote nodes sit idle despite being paired, connected, and advertising system.run. Users must mount all shared resources (NAS, drives, etc.) on the gateway instead of on dedicated nodes. No workload distribution is possible. For setups where the gateway is a VPS or resource-constrained device, agents cannot leverage more capable local hardware. Additionally, attempting per-agent tools.exec.host/node config keys can cause spawn /bin/sh ENOENT errors that break agent exec entirely, requiring config removal and gateway restart to recover.
Additional information
Other Approaches Tried (all failed)