#openclaw gateway start wouldn't really start

1 messages · Page 1 of 1 (latest)

tired wagonBOT
#

On Windows, openclaw gateway start just tells the background service to start — if the service isn’t installed, or the gateway starts then immediately crashes/exits, it can look like “nothing happened”.

1) First: are you in WSL2 or native Windows?

  • If you installed OpenClaw inside WSL2, you must run the gateway commands inside WSL, not plain PowerShell:
    wsl
openclaw gateway status
  • If you installed it natively (npm on Windows), keep using PowerShell.

2) Paste these 2 outputs (they’re the fastest signal)

Run and paste exact output:

openclaw --version
openclaw gateway status
#

openclaw gateway status is the key one — it usually shows:

  • Runtime: running/stopped
  • RPC probe: ok/failed
  • the Probe target URL
  • and often a Last gateway error (port conflict, config issue, etc.)

3) If it still says nothing useful, grab the report + logs

openclaw status --all
openclaw logs --follow

status --all is safe to share (it redacts tokens) and usually tells us why it won’t stay up.

Common culprits (what I’ll be looking for in your gateway status)

  • Gateway start blocked: set gateway.mode=local → your config is in remote mode, so local gateway won’t start.
  • another gateway instance is already listening / EADDRINUSE → port 18789 already in use.
#
  • Config (cli) ≠ Config (service) → the service is reading a different config/profile than your shell.
  • refusing to bind ... without auth → you set a non-loopback bind without token/password configured.

Docs for this exact flow:

Drop the --version + gateway status output here and I’ll tell you the next exact step.

sacred stag
#

PS C:\Windows\system32> openclaw --version

openclaw gateway status
OpenClaw 2026.3.11 (29dc654)

🦞 OpenClaw 2026.3.11 (29dc654) — One CLI to rule them all, and one more restart because you changed the port.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-03-13.log

Config (cli): ~.openclaw\openclaw.json (missing)
Config (service): ~.openclaw\openclaw.json (missing)

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (state Ready, last run time 3/13/2026 3:23:43 PM, Task status is locale-dependent and no numeric Last Run Result was available.)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway url override requires explicit credentials
Fix: pass --token or --password (or gatewayToken in tools).
Config: C:\Users\glysh.openclaw\openclaw.json

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

tired wagonBOT
#

That output is super helpful — two things jump out:

1) Your CLI probe is being blocked by a OPENCLAW_GATEWAY_URL / CLAWDBOT_GATEWAY_URL override

This line is the giveaway:

gateway url override requires explicit credentials
Fix: pass --token or --password …

That only happens when you have a gateway URL override set via env var (it’s a safety feature so OpenClaw won’t silently send credentials to an override URL).

In PowerShell, check + clear it:

echo "OPENCLAW_GATEWAY_URL=$env:OPENCLAW_GATEWAY_URL"
echo "CLAWDBOT_GATEWAY_URL=$env:CLAWDBOT_GATEWAY_URL"
# 
Remove-Item Env:OPENCLAW_GATEWAY_URL -ErrorAction SilentlyContinue
Remove-Item Env:CLAWDBOT_GATEWAY_URL -ErrorAction SilentlyContinue

Then re-run:

openclaw gateway status

(If the env var keeps coming back, it’s set permanently in your Windows Environment Variables — remove it there too.)

2) Your gateway config file doesn’t exist yet

Both say:

  • Config (cli): ~\.openclaw\openclaw.json (missing)
#
  • Config (service): ~\.openclaw\openclaw.json (missing)

Missing config is allowed, but it usually means you haven’t run onboarding yet. The simplest way to get a known-good setup (and a proper service install) is:

openclaw onboard --install-daemon

Next: confirm whether anything is actually listening on 18789

After clearing the env override, run this and paste output:

openclaw gateway start
openclaw gateway status
openclaw status
#

If it still won’t come up, also paste the Scheduled Task details (this shows the real “last run result” / command path):

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

Docs references:

Send the updated openclaw gateway status after clearing the env var — that’ll tell us immediately if it’s (a) not starting, or (b) starting but failing instantly with a real error (port conflict, auth/bind issue, etc.).

sacred stag
#

PS C:\Windows\system32> openclaw gateway status

🦞 OpenClaw 2026.3.11 (29dc654) — Alexa, but with taste.

|
o
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-03-13.log

Config (cli): ~.openclaw\openclaw.json (missing)
Config (service): ~.openclaw\openclaw.json (missing)

Gateway: bind=loopback (127.0.0.1), port=18789 (env/config)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (state Ready, last run time 3/13/2026 3:32:10 PM, Task status is locale-dependent and no numeric Last Run Result was available.)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway url override requires explicit credentials
Fix: pass --token or --password (or gatewayToken in tools).
Config: C:\Users\glysh.openclaw\openclaw.json

Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

i have openclaw installed under my F drive instead, could that be the problem

tired wagonBOT
#

Installing OpenClaw “on F:” is usually not a problem by itself — OpenClaw’s state/config still lives in C:\Users\glysh\.openclaw\… unless you changed OPENCLAW_STATE_DIR.

What is blocking us right now is this line (still present):

gateway url override requires explicit credentials

That means you have OPENCLAW_GATEWAY_URL (or CLAWDBOT_GATEWAY_URL) set in your environment somewhere, and OpenClaw refuses to probe the gateway unless you also pass a token/password (security measure).

1) Check whether the override is set (session + permanent)

Run this in PowerShell and paste the output:

echo "session OPENCLAW_GATEWAY_URL=$env:OPENCLAW_GATEWAY_URL"
echo "session CLAWDBOT_GATEWAY_URL=$env:CLAWDBOT_GATEWAY_URL"

[Environment]::GetEnvironmentVariable("OPENCLAW_GATEWAY_URL","User")
# 
[Environment]::GetEnvironmentVariable("OPENCLAW_GATEWAY_URL","Machine")
[Environment]::GetEnvironmentVariable("CLAWDBOT_GATEWAY_URL","User")
[Environment]::GetEnvironmentVariable("CLAWDBOT_GATEWAY_URL","Machine")

If any of those return a value, remove it (at least temporarily) and then re-run openclaw gateway status:

Remove-Item Env:OPENCLAW_GATEWAY_URL -ErrorAction SilentlyContinue
Remove-Item Env:CLAWDBOT_GATEWAY_URL -ErrorAction SilentlyContinue
openclaw gateway status

(If it’s set at User/Machine level, you’ll need to delete it in Windows Environment Variables too, otherwise it’ll come back in new terminals.)

2) Separate question: is the Scheduled Task actually failing to launch?

#

Because Runtime: unknown (state Ready …) suggests it’s not running now (it might be starting and immediately exiting).

Please paste:

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

That will show the “Task To Run” / action path. This is where your “installed on F:” could matter: if the scheduled task points to an old node.exe / openclaw path that no longer exists, it will never start.

3) Quick sanity check (optional, but fast)

This tells us whether anything is listening on the port:

Test-NetConnection 127.0.0.1 -Port 18789
#

Once you paste (1) the env var outputs + (2) the scheduled task details, I can tell you exactly whether this is:

  • just the env override breaking the probe, or
  • the gateway task actually failing due to a bad path (common after moving Node/npm installs).
sacred stag
#

PS C:\Windows\system32> echo "session OPENCLAW_GATEWAY_URL=$env:OPENCLAW_GATEWAY_URL"

echo "session CLAWDBOT_GATEWAY_URL=$env:CLAWDBOT_GATEWAY_URL"

session OPENCLAW_GATEWAY_URL=
session CLAWDBOT_GATEWAY_URL=
PS C:\Windows\system32> Test-NetConnection 127.0.0.1 -Port 18789
WARNING: TCP connect to (127.0.0.1 : 18789) failed

ComputerName : 127.0.0.1
RemoteAddress : 127.0.0.1
RemotePort : 18789
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : 127.0.0.1
PingSucceeded : True
PingReplyDetails (RTT) : 0 ms
TcpTestSucceeded : False

tired wagonBOT
#

Test-NetConnection confirms it: nothing is listening on 127.0.0.1:18789, so the Gateway really isn’t running right now.

Installing on F: can be the problem if the Scheduled Task (or its gateway.cmd) points at an openclaw/node.exe path on F: that doesn’t exist (or isn’t accessible under the task’s context). Let’s verify that directly.

1) Show the Scheduled Task “Last Run Result” + what it runs

Run and paste this:

schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

I’m specifically looking for:

  • Last Run Result (often a 0x… code)
  • Task To Run (the path it executes)

2) Show the generated task script (this usually reveals the bad path)

This file is what the Scheduled Task actually executes:

# 
type "$env:USERPROFILE\.openclaw\gateway.cmd"

(If that file doesn’t exist, that alone explains why the task can’t start.)

3) Quick “does the gateway work at all?” test (foreground)

This bypasses the Scheduled Task completely:

openclaw gateway run
  • If this works and the port opens, the gateway itself is fine → we just need to reinstall/fix the Scheduled Task (usually openclaw gateway install --force or openclaw onboard --install-daemon).
  • If this errors, paste the error + the last ~50 lines of the log file it mentioned:
    ~\AppData\Local\Temp\openclaw\openclaw-2026-03-13.log (you can Get-Content ... -Tail 80).
#

One more thing: the “gateway url override requires explicit credentials” message

You didn’t run the full checks yet. Please also paste these two lines (Machine scope can still be set even if the session is empty):

[Environment]::GetEnvironmentVariable("OPENCLAW_GATEWAY_URL","Machine")
[Environment]::GetEnvironmentVariable("CLAWDBOT_GATEWAY_URL","Machine")

Once you paste (1) + (2), I can tell you exactly whether the task is pointing at the wrong F: path, missing gateway.cmd, or failing with a specific 0x error code.

#

Yep — we’ve got the concrete reason now.

What’s happening

Your Scheduled Task is configured to run:

  • Task To Run: C:\Users\glysh\.openclaw\gateway.cmd

…but that file does not exist:

  • Cannot find path 'C:\Users\glysh\.openclaw\gateway.cmd' because it does not exist.
  • Last Result: 1 (task failed immediately)

So openclaw gateway start does trigger the task, but the task instantly fails because the script it’s supposed to run is missing. That’s why nothing is listening on port 18789.

Fix (re-generate gateway.cmd and refresh the task)

Run:

# 
openclaw gateway install --force
openclaw gateway start
openclaw gateway status

Then re-check the port:

Test-NetConnection 127.0.0.1 -Port 18789

If gateway install --force errors

Paste the full output. If it complains about permissions, try running PowerShell as your normal user first (the task itself is “Run As User: glysh”), and if needed then as Administrator.

After it’s running

Since your config is also missing (~\.openclaw\openclaw.json), I’d recommend doing the proper first-time setup once the gateway can start:

# 
openclaw onboard --install-daemon

Reply with the output of openclaw gateway install --force if it doesn’t recreate the script.

#

openclaw gateway start doesn’t “pick up whatever gateway.cmd you have lying around” — on Windows it starts the installed Scheduled Task named OpenClaw Gateway, and that task runs whatever Task To Run is configured to.

Right now your task is configured to run:

  • C:\Users\glysh\.openclaw\gateway.cmd

…and that file is missing, so the task exits immediately (Last Result: 1).

So even if you have a valid script at F:\openclaw-state\gateway.cmd, the service won’t use it unless the task was installed with OPENCLAW_STATE_DIR=F:\openclaw-state (or the task’s “Task To Run” points there).

Fix: make the service and your state dir agree

Option A (recommended): actually use F:\openclaw-state as the state dir everywhere

  1. In PowerShell for this session, set the state dir:
$env:OPENCLAW_STATE_DIR = "F:\openclaw-state"
#
  1. Re-install the Scheduled Task (this recreates gateway.cmd in that state dir and updates the task to run it):
openclaw gateway install --force
openclaw gateway start
  1. Verify it now points at F: and is listening:
schtasks /Query /TN "OpenClaw Gateway" /FO LIST
Test-NetConnection 127.0.0.1 -Port 18789
openclaw gateway status
  1. If you want this to persist across reboots/new terminals, set it permanently (then open a new PowerShell):
setx OPENCLAW_STATE_DIR "F:\openclaw-state"