The issue:

[pseudo dove]

The guardrailed broken one:

Here’s the concrete state on this machine (the one you’re chatting):

1. Gateway / OpenClaw status

• openclaw status shows the gateway is reachable and WhatsApp is connected.
• It also says: Memory plugin enabled but “unavailable” (so there’s no usable persistent memory store right now).
• It flags a security issue: gateway.controlUi.allowInsecureAuth=true (token-only auth over HTTP).

2. Gateway service vs interactive

• openclaw gateway status shows the Scheduled Task service is “stopped (Ready)” and “likely exited immediately.”
• Despite that, the gateway port is listening on 0.0.0.0:18789, and your chat is working—so the gateway is running some other way (likely an interactive/foreground process), not via the Scheduled Task service.

3. Nodes

• nodes status → no nodes ([]).

So what’s the issue, in plain terms?

• You want “open CMD / press 2 on my computer.”
• But nodes are empty, and OpenClaw backend exec does not automatically equal “control the visible desktop UI.”
• Your other machines probably have either:
  • a node paired (so the gateway can run on that machine), and/or
  • a different setup that includes UI automation / running in the interactive session consistently, and/or
  • the missing tools installed (scrcpy, your launcher script).

What to do next (pick one)

A) Make this behave like the others by pairing nodes

• Tell me: do you want the Windows laptop and/or Mac mini paired to this gateway?
• Then we’ll run openclaw node run ... on each and approve with openclaw devices approve ....

B) If your goal is Android control (scrcpy)

• We need to install scrcpy on this Windows host (it’s not found right now) and/or add it to PATH, plus whatever clear-bi is.

If you answer just this: “I want to pair my Windows laptop” (or Mac mini), I’ll give you the exact commands for that OS and walk you through approval.

The working non-broken one:

Here’s my actual status on this machine (run just now), so you can compare to what “it” told you:

1. Gateway / OpenClaw status (openclaw status)

• Security audit: 0 critical · 1 warn · 1 info
  • WARN: Reverse proxy headers are not trusted (gateway.bind is loopback and trustedProxies empty)
• Channels table is empty in the CLI output (your current chat is via webchat; CLI doesn’t list it there).
• Sessions: agent:main:main active on gpt-5.3-codex, ~22k/272k (8%).

2. Gateway service vs interactive (openclaw gateway status)

• Service: Scheduled Task (registered)
• Gateway is loopback-only: bind=127.0.0.1, port 18789
• Runtime: stopped (Ready) (service not running)
• RPC probe: ok
• Listening: 127.0.0.1:18789
  So: the service wrapper is stopped, but the gateway is still reachable/listening locally (same as what we observed earlier).

3. Nodes

• nodes status → [] (no paired nodes)

Important correction to the pasted status you got

It claimed “listening on 0.0.0.0:18789”. On this machine it’s 127.0.0.1:18789 (loopback only). That’s safer and matches the gateway status output.

If you want, paste the output of their openclaw status / openclaw gateway status commands (the raw text) and I’ll tell you exactly what’s different and what to change.

[smoky badge]

I would think you want to pair the nodes to make all this work. That seems to give the most flow. I'm sorry I don't understand enough to really help. Again, you might jump in #users-helping-users or open up a #1459642797895319552 request and the AI there will pop in, if it is working.

I would start at the beginning with your issue. First make sure everything is running properly, it appears from this description there are possible issues. Then make sure each session can see the other. Test them one on one and then try again to link them.

[pseudo dove]

Opus 4.6 Response:

Looking at both configurations, here's the key difference and fix:

The Core Problem

The "broken" machine has gateway.bind on 0.0.0.0:18789 (all interfaces), while the working one binds to 127.0.0.1:18789 (loopback only). This is why the broken one also flags gateway.controlUi.allowInsecureAuth=true as a security issue — it's accepting token-only auth over HTTP on a publicly exposed port.

What's Actually Different

	Broken	Working
Bind address	0.0.0.0:18789	127.0.0.1:18789
Security warnings	allowInsecureAuth=true flagged	Reverse proxy trust warning (benign)
Memory plugin	Enabled but "unavailable"	Not mentioned (likely not enabled)
Nodes	[]	[]
Service	Stopped, but gateway running (foreground)	Stopped, but gateway reachable (same)

The Fix

1. Lock down the bind address — In the gateway config (likely openclaw.yaml or equivalent), change:

gateway:
  bind: "127.0.0.1"
  port: 18789

This stops exposing the gateway to the network. If it was intentionally on 0.0.0.0 for remote access, put a reverse proxy (nginx/Caddy with HTTPS) in front and set trustedProxies accordingly.

2. Disable insecure auth once binding is fixed:

gateway:
  controlUi:
    allowInsecureAuth: false

3. Memory plugin — either fix the backing store (Redis, SQLite, whatever it expects) or disable the plugin entirely if you don't need it. It being "enabled but unavailable" suggests a missing or misconfigured database connection. Check the plugin config for a connection string and verify the store is actually running.

4. The "nodes are empty" issue is the same on both machines — neither has paired nodes. This is normal if you're only using webchat. If you need desktop/Android control (scrcpy, UI automation), you'll need to pair nodes on both, not just the broken one.

The broken one isn't deeply broken — it's mostly a misconfigured bind address creating a security exposure, plus a dead memory plugin. Fix those two things and it should match the working one's behavior.

[smoky badge]

I usually find Opus 4.6 more brainstorm worthy than Codex btw. If you have both, get a second opinion 🙂

ah 🙂

[pseudo dove]

I would use GPT-5.3 but the ChatGPT Desktop app is still not available with it.

I could load up Codex on VS Code for GPT-5.3-Codex High but it adds more steps.

[pseudo dove]

The idea is to to figure out as much as possible with what is working and what isn't, then send that all to a SOTA model.

There's no need to use our thinking until even the SOTA-level one doesn't work.

If you are adding your/our thinking, we could be wasting time and energy.

We shouldn't be troubleshooting unnecessarily.

We need to figure out wtf is going on and generate a solution.

If we want to troubleshoot for fun, we play video games against other people.

Now, with that said, the broken one said it's fixed, but CMD still does not open:

What I *can* do:
- run commands in a backend CMD/PowerShell session and show you the output here, or
- tell you how to open CMD locally: **Win + R → `cmd` → Enter**.

If you tell me what you want to run in CMD, I’ll run it for you backend-side (or give you the exact copy/paste line for your local CMD).```