openclaw - 💡(How to fix) Fix [Bug]: Agent shell tool ignores /exec host=node and still runs in container [1 pull requests]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

After /exec host=node node=<remote-macos-node> security=full ask=off, agent shell/exec commands still execute in the gateway/container Linux environment instead of the selected macOS node.

Steps to reproduce

1. Run OpenClaw gateway on a Linux gateway/container host.
2. Connect a macOS node, for example <remote-macos-node>.
3. In a TUI session, set node execution for the session:

   /exec host=node node=<remote-macos-node> security=full ask=off

4. Ask the agent to run a shell command that identifies the execution host:

   uname -s && hostname && pwd && whoami

5. Restart TUI and retry in the same session.
6. Start a new TUI session and retry the same /exec host=node node=<remote-macos-node> ... flow.

Expected behavior

When the session exec defaults select host=node and node=<remote-macos-node>, subsequent agent shell/exec tool calls in that session should execute on the selected macOS node and report Darwin / the node environment.

The gateway/container should remain the default runtime for sessions without this explicit /exec host=node ... session override.

Actual behavior

The /exec command is accepted and the session appears to have the node exec default set, but the next available agent shell tool still executes in the Linux container on the gateway host.

Observed output from the shell command:

uname=Linux
hostname=<gateway-container-hostname>
pwd=/home/node/.openclaw/workspace
whoami=node

Restarting TUI did not change the result. A fresh TUI session also still returned Linux after setting /exec host=node node=<remote-macos-node> ....

OpenClaw version

2026.5.12

Operating system

Gateway/runtime: Linux container host Node: macOS node Client: TUI over SSH

Install method

Gateway/container runtime; exact install method not verified from this report.

Model

openai/gpt-5.5

Provider / routing chain

TUI → OpenClaw gateway/session on Linux gateway/container host → OpenAI Codex agent runtime/tool bridge → agent shell/exec command

Additional provider/model setup details

The TUI status line shows Runtime: OpenAI Codex / openai/gpt-5.5. This appears to refer to the OpenAI OAuth/provider runtime used by OpenClaw, not the Codex CLI.

Logs, screenshots, and evidence

The node access work immediately before this test established:
- The macOS node is connected as an optional trusted node.
- Node exec approvals are set to security=full, ask=off, askFallback=full.
- File transfer for allowed macOS node paths works.
- Normal agent exec still runs on the Linux gateway/container by default.

Then, after setting /exec host=node node=<remote-macos-node>, the agent shell check still returned:

uname=Linux
hostname=<gateway-container-hostname>
pwd=/home/node/.openclaw/workspace
whoami=node

The behavior persisted after closing/restarting TUI and after trying a new session.

Related prior issue: #20669 reported the same class of failure (Agent exec ignores node binding — always routes to gateway despite correct config). That issue was closed as stale/not planned, with the bot saying to open a new issue with fresh repro steps if it still happens on a later release. This is a fresh repro on 2026.5.12.

Impact and severity

Affected: users who want OpenClaw to keep gateway/container as the default runtime while allowing the agent to explicitly use a paired local or remote node for node-local work.

Severity: High for multi-node workflows. The user can connect and configure a macOS node, but the agent shell path does not honor the session node routing and still runs in the gateway/container.

Frequency: 100% in the observed tests: same session after restart and fresh session both returned Linux after /exec host=node node=<remote-macos-node>.

Consequence: node-local files/apps/environment cannot be accessed through the normal agent shell execution path. The setup can only use separate node/file-transfer surfaces, while the main shell tool remains bound to the gateway/container.

Additional information

A likely source-level area to inspect is the bridge between session exec defaults and the OpenAI Codex agent runtime's exec_command shell tool. The generic OpenClaw exec docs imply host=node is supported, but the observed shell tool appears to spawn in the local container instead of going through the node exec router.

This report is intentionally limited to the observed behavior. I have not confirmed whether direct CLI openclaw nodes run --node <remote-macos-node> ... succeeds in this exact environment.