All OpenClaw Commands Slow

[dense forge]

Every time I do anything with openclaw through the CLI it takes about 30-45 seconds to get a response from the system. It used to run within 5-10 secs when I started using the claw.
Another machine I have runs everything either instantaneously or within a few seconds. Both are running 5.12.
The slower one has a couple of better specs in the system. Both are running windows.
I have ran doctor --deep and tried reinstalling the gateway.
What can I do to make it run faster?

[old shoal]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[copper raven]

First split this into “CLI startup is slow” vs “gateway calls are slow”:

Measure-Command { openclaw --version }
Measure-Command { openclaw gateway status }
Measure-Command { openclaw status }
openclaw status --all

If openclaw --version itself takes 30-45s, that’s probably Windows/runtime startup: check Windows Defender/AV exclusions for your OpenClaw install + state dirs, confirm Node is healthy/current, and compare native Windows vs WSL2. The docs still recommend WSL2 as the more stable Windows path for the full CLI/Gateway experience: https://docs.openclaw.ai/platforms/windows

If --version is fast but gateway status / status is slow, focus on the gateway/service path:

openclaw gateway status --json
openclaw health --verbose

[copper raven]

openclaw logs --follow

Look for slow connection/auth retries, gateway restart loops, repeated health probe failures, or a weird probe URL. Also worth checking Task Manager while a command hangs: if node.exe, schtasks.exe, or Defender is pegged, that’s a strong clue. Native Windows uses Scheduled Tasks first for gateway service management, and the docs call that out as an area with caveats.

Please paste:

• exact openclaw --version output from both machines
• the three Measure-Command timings
• openclaw gateway status --json from the slow one

Docs for the diagnostic ladder: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

[dense forge]

OpenClaw 2026.5.12 (f066dd2)

Measure-Command { openclaw --version }

Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 455
Ticks : 4553463
TotalDays : 5.27021180555556E-06
TotalHours : 0.000126485083333333
TotalMinutes : 0.007589105
TotalSeconds : 0.4553463
TotalMilliseconds : 455.3463

Measure-Command { openclaw gateway status }

Days : 0
Hours : 0
Minutes : 0
Seconds : 8
Milliseconds : 173
Ticks : 81731655
TotalDays : 9.45968229166667E-05
TotalHours : 0.00227032375
TotalMinutes : 0.136219425
TotalSeconds : 8.1731655
TotalMilliseconds : 8173.1655

Measure-Command { openclaw status }

Days : 0
Hours : 0
Minutes : 2
Seconds : 11
Milliseconds : 101
Ticks : 1311011238
TotalDays : 0.00151737411805556
TotalHours : 0.0364169788333333
TotalMinutes : 2.18501873
TotalSeconds : 131.1011238
TotalMilliseconds : 131101.1238

{
"cli": {
"version": "2026.5.12",
"entrypoint": "[REDACTED]\AppData\Roaming\npm\node_modules\openclaw\openclaw.mjs"
},
"logFile": "[REDACTED]\AppData\Local\Temp\openclaw\openclaw-2026-05-16.log",
"service": {
"label": "Scheduled Task",
"loaded": true,
"loadedText": "registered",
"notLoadedText": "missing",
"command": {
"programArguments": [
"C:\Program Files\nodejs\node.exe",
"[REDACTED]\AppData\Roaming\npm\node_modules\openclaw\dist\index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_GATEWAY_PORT": "18789"
},
"environmentValueSources": {
"TMPDIR": "inline",
"OPENCLAW_GATEWAY_PORT": "inline",
"OPENCLAW_SYSTEMD_UNIT": "inline",
"OPENCLAW_WINDOWS_TASK_NAME": "inline",
"OPENCLAW_SERVICE_MARKER": "inline",
"OPENCLAW_SERVICE_KIND": "inline",
"OPENCLAW_SERVICE_VERSION": "inline"
},
"sourcePath": "[REDACTED]\.openclaw\gateway.cmd"
},
"runtime": {
"status": "running",
"pid": 41508,
"detail": "Verified gateway listener detected on port 18789 even though schtasks did not report a running task.",
"state": "Ready",
"lastRunTime": "5/14/2026 11:03:32 PM",
"lastRunResult": "1"
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "C:\[REDACTED]\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": false
}
},
"daemon": {
"path": "[REDACTED]\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
}

},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "busy",
"listeners": [
{
"pid": 41508,
"address": "127.0.0.1:18789",
"command": "node.exe",
"commandLine": ""node" "[REDACTED]\npm\\node_modules\openclaw\openclaw.mjs" gateway --verbose"
}
],
"hints": []
},
"rpc": {
"ok": true,
"kind": "connect",
"capability": "connected_no_operator_scope",
"auth": {
"role": "operator",
"scopes": [],
"capability": "connected_no_operator_scope"
},
"server": {
"version": "2026.5.12",
"connId": "[REDACTED]"
},
"url": "ws://127.0.0.1:18789"
},
"extraServices": []
}

[copper raven]

Good, this rules out “PowerShell/OpenClaw executable startup” pretty cleanly. --version at 455ms is healthy.

The 8s gateway status strongly suggests the gateway probe is waiting on a slow/failing target before it gets an answer. The 2m11s status is unusually high and probably multiple diagnostics/probes/log reads stacking up.

Can you run these on the slow machine?

Measure-Command { openclaw gateway status --no-probe }
openclaw gateway status --json
Measure-Command { openclaw health --timeout 2500 }
Measure-Command { openclaw status --timeout 2500 }
openclaw status --all

What I’m looking for:

• if gateway status --no-probe is fast, the Windows service lookup is fine and the delay is the WebSocket/RPC probe
• in gateway status --json, check whether it’s probing more than one target, especially a stale gateway.remote.* URL or old localhost/port

[copper raven]

• if health --timeout 2500 is slow/fails, the gateway itself is sluggish or auth/connect is retrying
• status --all is the useful safe report, but if it also takes 2 minutes, paste the top diagnosis bits and any warnings

Also compare this on the fast machine:

openclaw config get gateway
openclaw gateway status --json

If the slow machine has a stale remote gateway URL, dead Tailscale hostname, old port, or token/auth mismatch, status can spend most of its time waiting for those probes to time out. Docs for the exact status flags: https://docs.openclaw.ai/cli/status and gateway status flags: https://docs.openclaw.ai/cli/gateway

[copper raven]

That snippet has two useful clues:

1. openclaw --version is fast, so Node/npm startup is not the core problem.
2. The gateway service state is odd: lastRunResult: "1" means the Scheduled Task last exited with an error, but OpenClaw still found a gateway listener on port 18789 at PID 41508.

So I’d check whether you have a stale/manual gateway process, or a task that fails and then a fallback process keeps the port open.

Please run:

Get-CimInstance Win32_Process -Filter "ProcessId = 41508" | Select-Object ProcessId,ExecutablePath,CommandLine
Measure-Command { openclaw gateway status --no-probe }
openclaw gateway status --json

Also, your pasted JSON cuts off before the important rpc / probe section. That section should show which URL(s) are being probed and whether auth/read capability is slow or failing.

[copper raven]

A clean reset to try after grabbing that info:

openclaw gateway restart
Measure-Command { openclaw gateway status }
Measure-Command { openclaw status --timeout 2500 }

If gateway status --no-probe is fast but regular gateway status is ~8s, the delay is definitely the connectivity/auth probe, not Windows service lookup. If the PID command shows a different install path or old OpenClaw path, then you likely have two installs/processes fighting over port 18789.

[copper raven]

This is the smoking gun:

listener commandLine: "node" "...\openclaw.mjs" gateway --verbose
scheduled task command: "C:\Program Files
odejs
ode.exe" "...\dist\index.js" gateway --port 18789
rpc capability: connected_no_operator_scope

So the process actually holding port 18789 is not the Scheduled Task command from your service config. It looks like a manually started / stale verbose gateway process. That also explains the Scheduled Task lastRunResult: 1: the task may be failing because the port is already occupied, while the old process keeps answering.

Try this cleanup path:

Stop-Process -Id 41508

[copper raven]

openclaw gateway restart
openclaw gateway status --json
Measure-Command { openclaw status --timeout 2500 }

After restart, the port.listeners[0].commandLine should match the Scheduled Task path, not openclaw.mjs gateway --verbose.

The second issue is auth scope:

capability: connected_no_operator_scope
scopes: []

That means the CLI can connect, but it is not authenticated with operator.read, so detail/status RPCs are limited. Check token config after the process cleanup:

[copper raven]

openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token
openclaw gateway status --require-rpc --json

If token auth is missing or drifted, run:

openclaw doctor --generate-gateway-token
openclaw gateway restart

Relevant docs: https://docs.openclaw.ai/cli/gateway and token/device drift notes at https://docs.openclaw.ai/gateway/troubleshooting

[dense forge]

Can you tell me what you need me to do again?

[copper raven]

Yep. Run these in PowerShell on the slow machine:

Stop-Process -Id 41508
openclaw gateway restart
openclaw gateway status --json
Measure-Command { openclaw status --timeout 2500 }

Then paste the new openclaw gateway status --json output.

What we’re checking: the old process on port 18789 was started as openclaw.mjs gateway --verbose, but your installed service expects dist\index.js gateway --port 18789. After restart, the listener command line should match the service path.

If status is still slow after that, also run: