Per-agent exec node routing does not work (agents always exec on gateway)
✅Solved
Environment
OpenClaw Version: 2026.2.14 (c1feda1)
Gateway: Apple Silicon Mac mini (macOS Sequoia)
Remote nodes: 2x 2014 Mac minis, both paired and connected via LaunchDaemons
Expected Behavior
When a per-agent tools.exec.host and tools.exec.node are set in agents.list[N], that agent's exec commands should route to the specified remote node — not execute on the gateway.
Actual Behavior
All agent exec runs on the gateway regardless of per-agent config. Three approaches were tried, all failed:
1. Per-agent tools.exec.host / tools.exec.node
json{
"id": "archie",
"tools": {
"exec": {
"host": "node",
"node": "Storage"
}
}
}
Result: Config accepted, but hostname && whoami && pwd still returns the gateway host/user. Exec is not routed to the node.
Worse: These keys actively break agent exec. Another agent's shell stopped working entirely with spawn /bin/sh ENOENT until the per-agent tools.exec block was removed.
2. Global tools.exec.host = node
bashopenclaw config set tools.exec.host node
Result: No change in routing behavior. Agents still exec on gateway.
3. Top-level execNode on agent definition
My orchestrator agent found an execNode field in the schema source (Type.Optional(NonEmptyString | Null)), but it's not recognized by the config validator:
Error: Config validation failed: agents.list.1: Unrecognized key: "execNode"
Steps to Reproduce
Pair and connect a remote node (openclaw nodes status shows paired/connected)
Add tools.exec.host: "node" and tools.exec.node: "NodeName" to an agent in agents.list
Restart gateway
Send a message to the agent asking it to run hostname && whoami && pwd
Agent returns the gateway hostname/user, not the node's
Questions
Is per-agent exec routing to remote nodes a supported feature in 2026.2.14?
If so, what is the correct config key/path to assign an agent to a specific node?
Is execNode intended for a future release?
What is the current intended use case for remote nodes if not per-agent exec routing?
OpenClaw Version: 2026.2.14 (c1feda1)
Gateway: Apple Silicon Mac mini (macOS Sequoia)
Remote nodes: 2x 2014 Mac minis, both paired and connected via LaunchDaemons
Expected Behavior
When a per-agent tools.exec.host and tools.exec.node are set in agents.list[N], that agent's exec commands should route to the specified remote node — not execute on the gateway.
Actual Behavior
All agent exec runs on the gateway regardless of per-agent config. Three approaches were tried, all failed:
1. Per-agent tools.exec.host / tools.exec.node
json{
"id": "archie",
"tools": {
"exec": {
"host": "node",
"node": "Storage"
}
}
}
Result: Config accepted, but hostname && whoami && pwd still returns the gateway host/user. Exec is not routed to the node.
Worse: These keys actively break agent exec. Another agent's shell stopped working entirely with spawn /bin/sh ENOENT until the per-agent tools.exec block was removed.
2. Global tools.exec.host = node
bashopenclaw config set tools.exec.host node
Result: No change in routing behavior. Agents still exec on gateway.
3. Top-level execNode on agent definition
My orchestrator agent found an execNode field in the schema source (Type.Optional(NonEmptyString | Null)), but it's not recognized by the config validator:
Error: Config validation failed: agents.list.1: Unrecognized key: "execNode"
Steps to Reproduce
Pair and connect a remote node (openclaw nodes status shows paired/connected)
Add tools.exec.host: "node" and tools.exec.node: "NodeName" to an agent in agents.list
Restart gateway
Send a message to the agent asking it to run hostname && whoami && pwd
Agent returns the gateway hostname/user, not the node's
Questions
Is per-agent exec routing to remote nodes a supported feature in 2026.2.14?
If so, what is the correct config key/path to assign an agent to a specific node?
Is execNode intended for a future release?
What is the current intended use case for remote nodes if not per-agent exec routing?
Solution
Perfect.
If you want to maximize the chance it gets fixed quickly, add one more comment to the issue with the minimal repro + expected/actual, basically:
1.
2. CLI proof:
-
3. Discord proof (same gateway/version):
-
-
-
That combo makes it crystal clear it’s agent exec routing, not node health.
Also, if this thread is basically solved on the support side, please mark the solution (right‑click the solution message → Apps →
Mark Solution) so Answer Overflow indexes it.
If you want to maximize the chance it gets fixed quickly, add one more comment to the issue with the minimal repro + expected/actual, basically:
1.
openclaw nodes describe --node Vaultsystem.run10.0.0.2002. CLI proof:
-
openclaw nodes run --node Vault -- /bin/sh -lc 'uname -m; ipconfig getifaddr en0'x86_6410.0.0.2003. Discord proof (same gateway/version):
-
/verbose full-
/exec host=node node=<vault-nodeId> security=full ask=off-
execarm6410.0.0.191spawn /bin/sh ENOENTThat combo makes it crystal clear it’s agent exec routing, not node health.
Also, if this thread is basically solved on the support side, please mark the solution (right‑click the solution message → Apps →
Mark Solution) so Answer Overflow indexes it.
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
130,529Members
Resources
Was this page helpful?
