Bug Description

When using the Podman launcher (scripts/run-openclaw-podman.sh), setting OPENCLAW_GATEWAY_BIND in the .env file has no effect. The gateway always starts with --bind loopback regardless of the value in .env.

Root Cause

In scripts/run-openclaw-podman.sh, GATEWAY_BIND is evaluated before the .env file is sourced:

# Line 80 — evaluated first
GATEWAY_BIND="${OPENCLAW_GATEWAY_BIND:-loopback}"

# ...

# Line 96 — .env sourced too late
if [[ -f "$ENV_FILE" ]]; then
  set -a
  source "$ENV_FILE" 2>/dev/null || true
  set +a
fi

By the time .env is sourced and OPENCLAW_GATEWAY_BIND=lan is set, GATEWAY_BIND has already been assigned loopback.

Impact

Users who run the onboarding wizard and choose a non-loopback bind (e.g. lan) get OPENCLAW_GATEWAY_BIND=lan written to their .env. But the gateway still starts with --bind loopback, making the dashboard unreachable from any non-loopback address — including WSL, LAN clients, or remote browsers.

The workaround is to prefix every launch command with the env var explicitly:

OPENCLAW_GATEWAY_BIND=lan ./scripts/run-openclaw-podman.sh launch

which is non-obvious and undocumented.

Steps to Reproduce

1. Run ./scripts/run-openclaw-podman.sh launch setup and choose lan bind
2. Confirm ~/.openclaw/.env contains OPENCLAW_GATEWAY_BIND=lan
3. Run ./scripts/run-openclaw-podman.sh launch
4. Check the running process: ps aux | grep gateway

Expected

node dist/index.js gateway --bind lan --port 18789

Actual

node dist/index.js gateway --bind loopback --port 18789

Environment

• OS: Linux (WSL2 on Windows 10)
• Runtime: rootless Podman