7 replies

LAN bind blocks subagent spawns + CLI — security check rejects ws:// to non-loopback

✅Solved

Setup: WSL2, gateway bound to

lan

lan

(need phone access over LAN), no TLS. Everything was working fine until subagent spawns started failing with:

SECURITY ERROR: Gateway URL "ws://<lan-ip>:<port>" uses plaintext ws:// to a non-loopback address.
Fix: Use wss:// for the gateway URL, or connect via SSH tunnel to localhost.

SECURITY ERROR: Gateway URL "ws://<lan-ip>:<port>" uses plaintext ws:// to a non-loopback address.
Fix: Use wss:// for the gateway URL, or connect via SSH tunnel to localhost.

Same error blocks

openclaw status

openclaw status

and any CLI command. The security check in

buildGatewayConnectionDetails

buildGatewayConnectionDetails

rejects any

ws://

ws://

URL that isn't loopback.

The gateway itself runs fine — it's the client-side connection (CLI, subagent spawner) that fails because

bind: "lan"

bind: "lan"

makes it resolve to the LAN IP.

Tried switching to

bind: "loopback"

bind: "loopback"

but then phone can't reach the dashboard (Windows port forward to loopback doesn't cross into WSL properly).

Is there a config field to override the client connection URL separately from the bind address? Something like a

gateway.clientUrl

gateway.clientUrl

or env var so the agent/CLI connects via

ws://127.0.0.1

ws://127.0.0.1

while the gateway still listens on

0.0.0.0

0.0.0.0

?

Or is the intended fix to set up TLS for LAN binds?

Version:

2026.2.19-2

2026.2.19-2

Solution

Important: do NOT point your gateway service at this file — the daemon must continue to run with the real service config (gateway.mode must be local for the daemon). Using OPENCLAW_CONFIG_PATH affects the CLI process only.

3) Proper / recommended: enable TLS for non-loopback binds
- Edit your Gateway config (the real daemon config), e.g. ~/.openclaw/openclaw.json:

{
"gateway": {
"bind": "lan",
"tls": {
"enabled": true,
"autoGenerate": true
},
"auth": { "mode": "token", "token": "YOUR_GATEWAY_TOKEN" }
}
}

- Restart the Gateway: openclaw gateway restart

Jump to solution

FotC�

Friends of the Crustacean 🦞🤝•3w ago•

7 replies

Qearl

LAN bind blocks subagent spawns + CLI — security check rejects ws:// to non-loopback

✅Solved

Setup: WSL2, gateway bound to

lan

lan

(need phone access over LAN), no TLS. Everything was working fine until subagent spawns started failing with:

SECURITY ERROR: Gateway URL "ws://<lan-ip>:<port>" uses plaintext ws:// to a non-loopback address.
Fix: Use wss:// for the gateway URL, or connect via SSH tunnel to localhost.

SECURITY ERROR: Gateway URL "ws://<lan-ip>:<port>" uses plaintext ws:// to a non-loopback address.
Fix: Use wss:// for the gateway URL, or connect via SSH tunnel to localhost.

Same error blocks

openclaw status

openclaw status

and any CLI command. The security check in

buildGatewayConnectionDetails

buildGatewayConnectionDetails

rejects any

ws://

ws://

URL that isn't loopback.

The gateway itself runs fine — it's the client-side connection (CLI, subagent spawner) that fails because

bind: "lan"

bind: "lan"

makes it resolve to the LAN IP.

Tried switching to

bind: "loopback"

bind: "loopback"

gateway.clientUrl

gateway.clientUrl

or env var so the agent/CLI connects via

ws://127.0.0.1

ws://127.0.0.1

while the gateway still listens on

0.0.0.0

0.0.0.0

?

Or is the intended fix to set up TLS for LAN binds?

Version:

2026.2.19-2

2026.2.19-2

Solution

Jump to solution

LAN bind blocks subagent spawns + CLI — security check rejects ws:// to non-loopback

LAN bind blocks subagent spawns + CLI — security check rejects ws:// to non-loopback

Similar Threads

Similar Threads

Similar Threads