openclaw - 💡(How to fix) Fix Feature Request: Per-sender exec node routing for multi-node setups [2 comments, 2 participants]

Summary

Currently, when multiple nodes connect to a single Gateway and each node runs its own TUI client, there is no way to automatically route exec calls back to the node that sent the message. The only exec routing options are:

• Global: tools.exec.host + tools.exec.node — all exec goes to one node
• Per-Agent: agents.list[i].tools.exec.node — different agents route to different nodes
• Per-Session: /exec host=node node=xxx — temporary session override

There is no per-sender / per-client routing that says "if the message comes from this TUI, exec on the same machine's node."

Problem to solve

My setup: one Gateway + multiple nodes. Each node runs its own TUI connected to the Gateway. I want each TUI to naturally execute commands on its own machine without explicitly specifying which node to use.

  Node A TUI → "ls Desktop" → exec on Node A
  Node B TUI → "ls Desktop" → exec on Node B
  WebChat    → "ls Desktop" → exec on Gateway

Currently this is impossible via configuration. The user must either hardcode a global node binding or manually specify the node per message.

Proposed solution

When a TUI client connects from the same device as a node host (i.e., they share the same device.id), the Gateway should be able to automatically route exec calls back to that device's node role.

This could be implemented as:

1. Auto-detection: If the sender's device.id matches a connected node's device.id, use that node for exec by default
2. New config: tools.exec.senderNodeRouting: true — enable per-sender routing when available
3. Fallback: If no matching node exists for the sender, fall back to current behavior (gateway or configured default)

Alternatives considered

• Moving the Gateway to the same machine — defeats the purpose of a shared Gateway
• Per-agent node binding — works but requires creating separate agents per node, which is cumbersome
• Prompt-level conventions (AGENTS.md) — fragile and depends on the model's judgment

Impact

Affected users/systems/channels: Users running a multi-node architecture where each node runs its own TUI client connected to a shared Gateway. This is the "one brain, many workstations" pattern.

Severity: Blocks the natural multi-node workflow. Users must either hardcode a single global node binding (losing flexibility) or manually specify the target node for every exec command.

Frequency: Always — every time a TUI user on a node sends a message that requires shell execution, the exec lands on the wrong machine unless explicitly overridden.

Consequence: Requires manual host=node node=xxx on every exec call, or prompt-level workarounds in AGENTS.md. This breaks the "just talk to my assistant" experience that works fine in single-machine setups.

Evidence/examples

No response

Additional information

The protocol already supports device identity (device.id in the connect handshake) and system-presence can show a single device with both operator and node roles. The infrastructure for detecting "same device, different roles" already exists — the exec routing layer just needs to use it.