Gateway start very slow | Friends of the Crustacean 🦞🤝 | Page 1

summer sand Apr 15, 2026, 3:41 PM

#

My discord gateway started in normal period, but loaded until the discord bot online is very slow

#

Here's my gateway log

22:38:05 [gateway] loading configuration…
22:38:07 [gateway] resolving authentication…
22:38:08 [gateway] starting...
22:38:34 [gateway] starting HTTP server...
22:38:34 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
22:38:34 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
22:38:34 [gateway] agent model: MODEL
22:38:34 [gateway] ready (6 plugins: acpx, browser, device-pair, discord, phone-control, talk-voice; 26.7s)
22:38:34 [gateway] log file:
22:38:35 [gateway] starting channels and sidecars...
22:38:35 [gateway] removed stale session lock:
22:38:35 [hooks] loaded 4 internal hook handlers
22:39:05 [bonjour] watchdog detected non-announced service; attempting re-advertise
22:39:05 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
22:39:14 [plugins] embedded acpx runtime backend registered
22:39:14 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
22:39:16 [heartbeat] started
22:39:17 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
22:39:17 [discord] [default] starting provider (@OpenClawy)
22:39:17 [discord] users resolved:
22:39:17 [plugins] embedded acpx runtime backend ready
22:39:19 [discord] client initialized as 1483445847722033315 (OpenClawy); awaiting gateway readiness

Hidded some of the path for security

timid bobcatBOT Apr 15, 2026, 3:44 PM

#

First thing, what does this show?

openclaw --version

If the gateway itself starts normally but the Discord bot takes a long time to show online, the fastest triage bundle is:

openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw logs --follow

Please paste:

#

openclaw --version
openclaw gateway status
openclaw channels status --probe
the Discord-related lines from openclaw logs --follow during startup

A few likely causes here:

slow/blocked network path to Discord
proxy/firewall/DNS issue
Discord startup REST lookups being delayed
slow host / VM / disk during startup

Also, if you use a proxy, Discord startup uses channels.discord.proxy for both gateway WebSocket traffic and startup REST lookups, so that is worth checking too.

Docs:

#

https://docs.openclaw.ai/channels/discord

Paste the outputs and I’ll help narrow it down.

summer sand Apr 15, 2026, 3:48 PM

#

C:\Users\User>openclaw status --all
OpenClaw status --all

Diagnosis
Gateway connection details:
Source: local loopback
Config: C:\Users\bhupa.openclaw\openclaw.json
Bind: loopback

✓ Config: C:\Users\bhupa.openclaw\openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 13756: "C:\Program Files\nodejs\node.exe" C:\Users\bhupa\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 12 eligible · 0 missing · C:\Users\bhupa.openclaw\workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

timid bobcatBOT Apr 15, 2026, 3:48 PM

#

Thanks, this status is actually pretty useful.

What it tells me:

Version 2026.4.14 is current
Discord config looks loaded fine
Port 18789 is already in use is not the problem here, it just means the gateway is already running on that port
the only suspicious line is: Agents: 1 total · 1 bootstrapping

So right now I do not see a Discord token/config failure from this output.
What I need next is the live Discord transport state and startup logs.

Please run these next:

openclaw gateway status

#

openclaw channels status --probe
openclaw logs --follow

If you can, also do one clean restart and watch the logs immediately after:

openclaw gateway restart
openclaw channels status --probe
openclaw logs --follow

What I want to know:

does Discord show connected quickly, or only after a long delay?
does that 1 bootstrapping clear, or stay stuck?

#

are there any Discord-related warnings/errors in the startup logs?

My guess so far: this is more likely a startup/runtime hang than a Discord token issue.

Docs:

Paste gateway status, channels status --probe, and the Discord lines from the logs, and I’ll narrow it down.

summer sand Apr 15, 2026, 3:50 PM

#

Gateway reachable.

Discord default: enabled, configured, running, connected, bot:@OpenClawy, token:config, intents:content=limited, works
Runtime: running (pid 13756, Startup-folder login item installed; listener detected on port 18789.)
RPC probe: ok

timid bobcatBOT Apr 15, 2026, 3:51 PM

#

That output actually looks healthy.

The key lines are:

running
connected
works
RPC probe: ok

So OpenClaw thinks the Discord transport is up and usable.
That means the slow part may be one of these:

Discord presence/UI lag
The green “online” indicator can appear a bit later than the bot actually becoming usable.
Native Windows startup timing
If this mainly happens right after Windows boot/login, the gateway may be starting before networking is fully settled.

#

Also, intents:content=limited is not what makes the bot come online slowly.

Quick test

When it feels “slow”, try this once:

openclaw gateway restart

If it comes online quickly after a manual restart, but is slow only on Windows startup, that points to a Windows auto-start timing issue, not a Discord config problem.

Safe next step

Run:

openclaw doctor

#

That is the recommended repair check from the docs.

One more useful detail

How long is “very slow” for you?

10 to 30 seconds: could just be Discord/client presence delay
1 to 2+ minutes: that is more likely a real startup issue

If this is a native Windows install, the docs also say WSL2 is the more stable path overall.

Docs:

If you want, send how many seconds/minutes it takes, and whether a manual openclaw gateway restart makes it come up fast.

summer sand Apr 15, 2026, 3:51 PM

#

Discord connected only after a long delay after this line : 22:38:35 [hooks] loaded 4 internal hook handlers
took almost 30 seconds to start gateway

timid bobcatBOT Apr 15, 2026, 3:51 PM

#

Got it, thanks, that helps.

If the gap is about 30 seconds after:

[hooks] loaded 4 internal hook handlers

then I’d call that a bit slow, but not wildly broken, especially on native Windows.

A couple important bits:

that [hooks] ... line is not the Discord-connected step, it is just earlier startup
your later probe already showed Discord as running, connected, works
so this looks more like startup latency, not a bad Discord config

Best way to narrow it down

#

Please try this once after Windows is fully settled:

openclaw gateway restart

If the manual restart connects much faster than the startup-at-login case, then the problem is probably:

Windows startup timing
network/DNS not fully ready yet
antivirus/firewall/proxy slowing Discord startup

If the manual restart is also ~30 seconds every time, then it is more likely just the native Windows path being a bit sluggish.

Safe repair step

#

openclaw doctor

If you want deeper diagnosis

Paste the next 20 to 30 log lines after:

[hooks] loaded 4 internal hook handlers

up to the line where Discord says connected/ready. That will show where the 30 seconds is being spent.

Also, docs do still recommend WSL2 as the more stable Windows path if you want the smoothest behavior:

#

So short version: 30s is slow, but with your current probe results it looks like startup latency, not a broken Discord setup.

summer sand Apr 15, 2026, 4:03 PM

#

23:01:36 [gateway] loading configuration…
23:01:37 [gateway] resolving authentication…
23:01:37 [gateway] starting...
23:02:05 [gateway] starting HTTP server...
23:02:05 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
23:02:05 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
23:02:06 [gateway] agent model: lm-studio/Jackrong/qwopus3.5-9b-v3-gguf
23:02:06 [gateway] ready (6 plugins: acpx, browser, device-pair, discord, phone-control, talk-voice; 28.8s)
23:02:06 [gateway] log file: \tmp\openclaw\openclaw-2026-04-15.log
23:02:06 [gateway] starting channels and sidecars...
23:02:07 [hooks] loaded 4 internal hook handlers
23:02:35 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
23:02:44 [plugins] embedded acpx runtime backend registered
23:02:44 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
23:02:46 [heartbeat] started
23:02:47 [plugins] embedded acpx runtime backend ready
23:02:47 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
23:02:47 [discord] [default] starting provider (@OpenClawy)
23:02:47 [discord] users resolved: 920199943136874506
23:02:49 [discord] client initialized as 1483445847722033315 (OpenClawy); awaiting gateway readiness

I ran it again, look is it normal? I feel like it take too long

timid bobcatBOT Apr 15, 2026, 4:05 PM

#

Yeah, that is a bit slow.

From your log, the important part is this:

23:01:37 [gateway] starting...
23:02:06 [gateway] ready ... (28.8s)
Discord does not even begin starting until 23:02:47

So the delay is not mainly Discord itself. The slow part is the gateway/bootstrap + sidecar/plugin startup before Discord fully comes up.

A few notes:

pricing bootstrap failed: TimeoutError means one startup lookup timed out, but it is non-fatal
you have several things starting: acpx, browser, device-pair, discord, phone-control, talk-voice
on native Windows, this is more believable than on Linux/WSL2, but it is still slower than ideal

So my honest read is:

#

not broken
not especially fast either
more of a Windows/startup overhead issue than a Discord config issue

What I’d do next

Run:

openclaw doctor

If you want the smoothest startup on Windows, docs still recommend WSL2:
https://docs.openclaw.ai/platforms/windows
If you want, I can help you figure out which startup piece is costing the most time and whether an unused plugin/feature is worth disabling. That is probably the next best path if your goal is faster boot.

summer sand Apr 15, 2026, 4:06 PM

#

yes, I want a faster boot

timid bobcatBOT Apr 15, 2026, 4:07 PM

#

Yep, then I’d optimize the startup path, not Discord itself.

From your log, the obvious boot cost is coming from other services starting before Discord. The two best low-hanging wins are usually:

Browser plugin
ACP runtime

If you do not use those, trimming them should help.

My recommendation

Best overall fix: use WSL2 on Windows, docs recommend it for the smoother path.
https://docs.openclaw.ai/platforms/windows

If you want to stay on native Windows, trim unused features first.

If you do not use the browser tool

#

Docs-backed way to disable the bundled browser plugin:

{
  plugins: {
    entries: {
      browser: {
        enabled: false,
      },
    },
  },
}

Docs: https://docs.openclaw.ai/tools/browser

If you do not use ACP sessions / Codex / Claude Code thread bindings

#

You can disable ACP:

{
  acp: {
    enabled: false,
  },
}

Docs: https://docs.openclaw.ai/tools/acp-agents

Also worth doing

openclaw doctor

#

That is the safe repair pass from the docs.

Why I’m pointing here

Your log shows Discord only starts near the end:

gateway core ready: 28.8s
then more startup work
then Discord begins

So I would not chase Discord intents/settings first.
I’d trim startup features first.

If you want, tell me:

do you use the browser tool?
do you use ACP / Codex / Claude Code style sessions?

#

and I’ll tell you the smallest safe config change to speed up boot.

summer sand Apr 15, 2026, 4:12 PM

#

what is WSL2 and how to use it?

timid bobcatBOT Apr 15, 2026, 4:12 PM

#

WSL2 is Windows Subsystem for Linux 2.

Plain English: it lets you run a real Linux environment, usually Ubuntu, inside Windows. For OpenClaw, that means you run the gateway in Linux instead of native Windows, and the docs recommend that path because it is usually more stable.

Why people use it for OpenClaw

smoother Linux tooling
better service behavior
often fewer weird Windows startup issues

Basic setup

1. Install WSL2 + Ubuntu
Open PowerShell as Administrator:

wsl --install

#

# or choose Ubuntu explicitly
wsl --list --online
wsl --install -d Ubuntu-24.04

Reboot if Windows asks.

2. Enable systemd in WSL
Open your Ubuntu terminal and run:

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

#

Then back in PowerShell:

wsl --shutdown

Re-open Ubuntu and verify:

systemctl --user status

3. Install OpenClaw inside WSL
Inside Ubuntu, easiest path is the Linux installer:

#

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

Important mindset

Once you move to WSL2, you run OpenClaw inside the Ubuntu terminal, not in normal Windows PowerShell.

Docs

https://docs.openclaw.ai/platforms/windows
https://docs.openclaw.ai/start/getting-started
Microsoft WSL guide: https://learn.microsoft.com/windows/wsl/install

If you want, I can give you the exact shortest step-by-step migration path from your current Windows install to WSL2 without losing track of what to do next.

summer sand Apr 15, 2026, 4:14 PM

#

I disabled acp and browser, it still take 30 second to fully loaded

timid bobcatBOT Apr 15, 2026, 4:15 PM

#

That’s actually a really useful result.

If disabling ACP and browser did not change the boot time, then those were not the bottleneck.

So the picture now is:

the slow part is core gateway startup on native Windows
not Discord config
not ACP/browser startup

What I’d do next

1. Run the repair check

openclaw doctor

#

2. Check whether the agent is still stuck bootstrapping
After startup, run:

openclaw status --all

and look at the Agents line.

Earlier you had:

1 total · 1 bootstrapping

If that is still there, that is the next suspect.

#

Honest recommendation

If doctor is clean and the agent is not stuck bootstrapping, then I would stop chasing plugin tweaks. At that point, ~30 seconds is probably just native Windows overhead on your setup, and WSL2 is the real fix if faster boot matters to you.

Docs:

If you paste the new Agents line from openclaw status --all, I can tell you whether this is a stuck-bootstrap problem or just Windows being slow here.

summer sand Apr 15, 2026, 4:19 PM

#

✓ Config: C:\Users\bhupa.openclaw\openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 6716: "C:\Program Files\nodejs\node.exe" C:\Users\bhupa\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789 (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
✓ Skills: 12 eligible · 0 missing · C:\Users\bhupa.openclaw\workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

Agents | 1 total · 1 bootstrapping · 0 active · 3 sessions

timid bobcatBOT Apr 15, 2026, 4:20 PM

#

Aha, that’s the real clue.

1 bootstrapping means OpenClaw still thinks the agent is in first-run bootstrap mode.

I checked the status logic, and that flag is basically: does BOOTSTRAP.md still exist in the workspace.

Per the docs, BOOTSTRAP.md is supposed to be removed after first-run finishes:
https://docs.openclaw.ai/start/bootstrapping

So check this file

On your setup it is likely here:

C:\Users\bhupa\.openclaw\workspace\BOOTSTRAP.md

If you already finished first-run setup

#

That file should not still be there.

Safest test:

rename it to something like BOOTSTRAP.md.bak
restart the gateway
run openclaw status --all again

If bootstrapping disappears after that, you found the cause.

Why this matters

A stuck bootstrap state can absolutely make startup feel wrong/slow, because OpenClaw keeps treating the workspace like it is still in first-run mode.

So at this point, I think this is more likely a stuck bootstrap file than a Discord issue.

If you want, after renaming that file, paste the new Agents line and I’ll confirm whether it fixed it.

summer sand Apr 15, 2026, 4:22 PM

#

o Install missing bundled plugin runtime deps now?
| Yes
Failed to install bundled plugin runtime deps: Error: npm install failed

what is this?? it's in openclaw doctor

timid bobcatBOT Apr 15, 2026, 4:23 PM

#

That is a different issue from the slow boot, and it is coming from openclaw doctor.

What it means:

OpenClaw has some bundled plugins
some of those plugins need extra npm runtime packages
doctor noticed one or more of those packages were missing
it offered to install them automatically
that auto-install step failed with npm install failed

So this is not “your Discord config is broken”.
It means doctor tried to repair missing bundled plugin dependencies and npm failed while doing it.

Docs section:
https://docs.openclaw.ai/gateway/doctor

Under the hood it is basically trying an npm install inside your OpenClaw install folder.

#

What I need from you

Please paste the lines just above that prompt, especially the part that says which packages were missing.

It usually looks something like:

Bundled plugin runtime deps are missing.
- package@version (used by plugin-id)
...

That will tell us whether this is:

something important for your current setup
or just a missing dep for a plugin you do not even use

So short version: doctor found missing plugin packages, tried to auto-fix them, and npm failed.

#

Paste the missing-package lines and I’ll tell you whether it matters.

summer sand Apr 15, 2026, 4:24 PM

#

o Config warnings --------------------------------------------------------------------------+
| |
| - plugins.entries.acp: plugin not found: acp (stale config entry ignored; remove it from |
| plugins config) |
| |
+--------------------------------------------------------------------------------------------+
|
o Doctor warnings ----------------------------------------------------------------------+
| |
| - plugins.entries.acp: stale plugin reference "acp" was found. |
| - Run "openclaw doctor --fix" to remove stale plugins.allow and plugins.entries ids. |
| |
+----------------------------------------------------------------------------------------+
|
o Bundled plugins ---------------------------------+
| |
| Bundled plugin runtime deps are missing. |
| - @discordjs/opus@^0.10.0 (used by discord) |
| Fix: run openclaw doctor --fix to install them. |
| |
+---------------------------------------------------+
|
o Install missing bundled plugin runtime deps now?
| Yes
Failed to install bundled plugin runtime deps: Error: npm install failed

timid bobcatBOT Apr 15, 2026, 4:24 PM

#

Nice, this clears it up a lot.

Two separate things are happening here:

1. `plugins.entries.acp` is stale config

This part:

plugins.entries.acp: plugin not found: acp

means the config entry is wrong/stale.

ACP is not a bundled plugin called acp.
If you want ACP off, the right knob is:

#

{
  acp: {
    enabled: false
  }
}

So yes, that stale plugins.entries.acp entry should be removed.

2. `@discordjs/opus` is missing

This part:

@discordjs/opus@^0.10.0 (used by discord)

#

is a Discord runtime dependency, mainly relevant for Discord voice / audio features.

If you are just using normal text chat, I do not think this is the main reason for your 30-second startup.

Also, because @discordjs/opus is a native module, npm install failures on Windows are unfortunately not unusual.

Most important point

I still think your main clue is this:

Agents | 1 total · 1 bootstrapping

That is more suspicious for your startup issue than the missing @discordjs/opus.

So I would focus on this first:

#

check whether C:\Users\bhupa\.openclaw\workspace\BOOTSTRAP.md still exists
if first-run is already done, rename it to BOOTSTRAP.md.bak
restart the gateway
check if bootstrapping disappears

Short version

stale plugins.entries.acp -> should remove
missing @discordjs/opus -> probably voice-related, not your main boot delay
1 bootstrapping -> still the strongest lead

Docs:

If you want, I can help you clean up the exact ACP config line next.

summer sand Apr 15, 2026, 4:29 PM

#

now it take almost 1 minute to fully loaded

Agents | 1 total · 0 bootstrapping · 0 active · 3 sessions

timid bobcatBOT Apr 15, 2026, 4:30 PM

#

Okay, that is actually useful progress.

0 bootstrapping means we did fix one real issue. I’m glad we caught that.

But almost 1 minute is still too slow, so there is another delay after bootstrap.

Next step

Please do one clean restart and paste the startup log block from:

[gateway] starting...

through the line where Discord is finally ready/connected.

The exact command:

#

openclaw gateway restart
openclaw logs --follow

What I want to see is the timestamps around:

[gateway] starting...
[gateway] ready ...
starting channels and sidecars...
any model-pricing timeout
[discord] starting provider
[discord] client initialized
the line where Discord becomes connected/ready

My read right now

bootstrapping issue is fixed

#

startup is still abnormally slow
so now we need the fresh post-fix startup log, because the old one is no longer the whole story

Docs:

https://docs.openclaw.ai/gateway/troubleshooting

Paste that fresh log block and I’ll help pinpoint the next bottleneck.

summer sand Apr 15, 2026, 4:30 PM

#

23:26:45 [gateway] starting HTTP server...
23:26:45 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
23:26:45 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
23:26:46 [gateway] agent model:
23:26:46 [gateway] ready (5 plugins: acpx, device-pair, discord, phone-control, talk-voice; 26.0s)
23:26:46 [gateway] log file: \tmp\openclaw\openclaw-2026-04-15.log
23:26:46 [gateway] starting channels and sidecars...
23:26:47 [hooks] loaded 4 internal hook handlers
23:27:22 [bonjour] watchdog detected non-announced service; attempting re-advertise host=openclaw.local. port=18789 state=probing)
23:27:22 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
23:27:37 [bonjour] restarting advertiser (service stuck in announcing for 15642ms (gateway fqdn=Bhupa-MAG (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing))
23:27:40 [plugins] embedded acpx runtime backend registered
23:27:42 [heartbeat] started
23:27:42 [plugins] embedded acpx runtime backend ready
23:27:42 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
23:27:42 [discord] [default] starting provider (@OpenClawy)
23:27:42 [discord] users resolved: 920199943136874506
23:27:45 [discord] client initialized as 1483445847722033315 (OpenClawy); awaiting gateway readiness

timid bobcatBOT Apr 15, 2026, 4:32 PM

#

Yep, this log finally shows something concrete.

The two biggest suspects now are:

Bonjour / mDNS advertising is getting stuck

[bonjour] watchdog detected non-announced service...
[bonjour] restarting advertiser (service stuck in announcing...)

The bundled acpx plugin is still loading
```
[plugins] embedded acpx runtime backend ready
```
and Discord only starts after that.

So this is no longer looking like “just Discord slow”.

#

My recommendation

Option 1, best first test: turn off Bonjour/mDNS

If you do not need LAN auto-discovery for nodes/remote control, try:

{
  discovery: {
    mdns: {
      mode: "off"
    }
  }
}

Tradeoff: you lose local network auto-discovery.

#

Docs:

Option 2, if you do not use ACP at all: disable the real plugin, `acpx`

Your logs show acpx is still loaded. The real bundled plugin id is acpx, not acp.

If you do not use ACP/Codex/Claude Code harnesses, disable that plugin, not the stale acp entry.

Docs:

https://docs.openclaw.ai/tools/acp-agents

Also worth noting

This line is still happening:

#

[model-pricing] pricing bootstrap failed: TimeoutError

That is another sign of startup doing an outbound lookup and timing out. Not fatal, but it can add noise/delay.

Short version

If I were you, I would test in this order:

disable mDNS/Bonjour
disable acpx if unused
restart and compare startup time

This log is the first one that really points at specific startup components instead of Discord itself.

If you want, I can help you write the smallest safe config snippet for turning off mdns and acpx cleanly.

summer sand Apr 15, 2026, 4:33 PM

#

{
"gateway": {
"mode": "local",
"auth": {
"mode": "token",
"token": "TOKEN"
},
"port": 18789,
"bind": "loopback",
"tailscale": {
"mode": "off",
"resetOnExit": false
},
"nodes": {
"denyCommands": [
"camera.snap",
"camera.clip",
"screen.record",
"contacts.add",
"calendar.add",
"reminders.add",
"sms.send",
"sms.search"
]
}
},
"session": {
"dmScope": "per-channel-peer"
},
"tools": {
"profile": "coding",
"web": {
"search": {
"provider": "searxng"
}
}
},
"skills": {},
"channels": {
"discord": {
"enabled": true,
"token": "TOKEN",
"groupPolicy": "open",
"dmPolicy": "allowlist",
"dm": {
"enabled": true
},
"allowFrom": [
"920199943136874506"
]
}
},
"hooks": {
"internal": {
"enabled": true,
"entries": {
"command-logger": {
"enabled": true
},
"session-memory": {
"enabled": true
}
}
}
},
"wizard": {
"lastRunAt": "2026-04-15T15:38:03.381Z",
"lastRunVersion": "2026.4.14",
"lastRunCommand": "doctor",
"lastRunMode": "local"
},
"meta": {
"lastTouchedVersion": "2026.4.14",
"lastTouchedAt": "2026-04-15T15:38:03.967Z"
},
"plugins": {
"entries": {
"searxng": {
"config": {
"webSearch": {
"baseUrl": "http://localhost:8080"
}
},
"enabled": true
},
"browser": {
"enabled": false
},
"acp": {
"enabled": false
}
}
}
}
Here's my .json file , (removed agents and model section)

timid bobcatBOT Apr 15, 2026, 4:34 PM

#

Yep, I can see two important things in that config:

plugins.entries.acp is wrong/stale
- doctor already warned about this
- the real bundled plugin is acpx, not acp
discovery.mdns is not set
- so mDNS/Bonjour is still using the default
- your logs showed Bonjour getting stuck, so this is worth testing

I would change it like this

{
  "discovery": {
    "mdns": {

#

      "mode": "off"
    }
  },
  "plugins": {
    "entries": {
      "searxng": {
        "config": {
          "webSearch": {
            "baseUrl": "http://localhost:8080"
          }
        },
        "enabled": true
      },
      "browser": {
        "enabled": false

#

      },
      "acpx": {
        "enabled": false
      }
    }
  }
}

And remove this stale bit

"acp": {
  "enabled": false
}

#

Why

acp there does nothing useful, and doctor flags it as stale
acpx is the actual bundled ACP runtime plugin
discovery.mdns.mode: "off" disables Bonjour/mDNS advertising, which your logs strongly suggest is hanging startup

What to do after

Restart the gateway and test boot time again.

Docs:

If you want, after you restart, paste the new startup log and I’ll compare it line-by-line.

summer sand Apr 15, 2026, 4:38 PM

#

23:36:29 [gateway] loading configuration…
23:36:30 [gateway] resolving authentication…
23:36:30 [gateway] starting...
23:36:56 [gateway] starting HTTP server...
23:36:56 [canvas] host mounted at
23:36:56 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
23:36:56 [gateway] agent model:
23:36:56 [gateway] ready (4 plugins: device-pair, discord, phone-control, talk-voice; 26.4s)
23:36:56 [gateway] log file:
23:36:57 [gateway] starting channels and sidecars...
23:36:57 [hooks] loaded 4 internal hook handlers
23:37:25 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
23:37:37 [heartbeat] started
23:37:37 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
23:37:37 [discord] [default] starting provider (@OpenClawy)
23:37:37 [discord] users resolved: 920199943136874506
23:37:39 [discord] client initialized as 1483445847722033315 (OpenClawy); awaiting gateway readiness

timid bobcatBOT Apr 15, 2026, 4:39 PM

#

This is much clearer now.

Good news first: the log is cleaner now, so those earlier tweaks were not pointless.

But the important part is this:

23:36:30 [gateway] starting...
23:36:56 [gateway] starting HTTP server...
23:36:56 [gateway] ready ... (26.4s)

So the main delay is happening before Discord even starts.

That means this is not really a Discord config problem anymore.
It is now looking like:

native Windows startup overhead, and/or
some remaining startup-time network lookup, especially this:

#

   [model-pricing] pricing bootstrap failed: TimeoutError

My honest read

At this point, I don’t see an obvious remaining config tweak that cleanly explains the full minute.

You already:

fixed the stuck bootstrap
removed Bonjour/mDNS delay
removed browser
removed ACP runtime startup

and the gateway still spends ~26 seconds before it is even ready.

What I’d recommend now

#

If faster boot really matters: move to WSL2.
That is the most practical next step.

If you want native Windows investigated: this is now bug-report territory, not “you set the wrong config key” territory. Please file a GitHub issue with:

your version: 2026.4.14
Windows version
the before/after startup logs you posted here
note that bootstrapping was fixed and mdns/acpx/browser were reduced but startup stayed slow

GitHub issues:
https://github.com/openclaw/openclaw/issues

So short version: we’ve ruled out the obvious config mistakes. What’s left looks like native Windows startup slowness or a real startup bug.

summer sand Apr 15, 2026, 4:40 PM

#

is re-installing openclaw will help fix this issue??

timid bobcatBOT Apr 15, 2026, 4:41 PM

#

Maybe, but I wouldn’t bet on it.

Based on your logs, a reinstall of the same native Windows setup is low-confidence for fixing this. The remaining delay looks more like native Windows startup/runtime slowness than a broken Discord config.

My honest recommendation

Reinstall on native Windows: possible, but not my first choice
Fresh install in WSL2: much better chance of actually improving boot time

If you do reinstall

Back up these first:

C:\Users\bhupa\.openclaw\openclaw.json
C:\Users\bhupa\.openclaw\workspace

That keeps your config/workspace safe.

Best use of your time

#

If you are willing to reinstall anyway, I would spend that effort on WSL2, not on reinstalling the same Windows path.

Docs:

So short version: same Windows reinstall might help a little, but WSL2 is the one I’d actually recommend.

summer sand Apr 15, 2026, 4:42 PM

#

ok I want to install it on WSL2, or is it better to change the channel to others? like line or telegram

timid bobcatBOT Apr 15, 2026, 4:43 PM

#

I’d separate those two questions:

If your goal is fix the slow boot

WSL2 is the better move.

Changing from Discord to Telegram/LINE probably will not fix the main issue, because your logs showed the gateway is already slow before Discord startup.

If your goal is use an easier channel

Telegram is the easiest one.

The docs literally call Telegram the fastest channel to set up, basically just a bot token:
https://docs.openclaw.ai/channels/telegram

My recommendation

Move OpenClaw to WSL2
Keep Discord if you like it
If you want a simpler chat channel afterward, add Telegram

#

So short version:

WSL2 = best fix for the startup problem
Telegram = best easy channel
Changing channel alone = probably not enough

Docs:

If you want, I can give you the shortest step-by-step WSL2 install plan next.

summer sand Apr 15, 2026, 4:44 PM

#

why others doesn't face the problem like me?

timid bobcatBOT Apr 15, 2026, 4:44 PM

#

Honestly, probably because you hit a specific combination of things that many others do not.

From your logs, you had a mix of:

native Windows
a stuck bootstrap state
Bonjour/mDNS weirdness
a model-pricing timeout
bundled plugin/runtime differences

That is a very machine-specific pileup.

Also, a lot of people who “don’t have this problem” are often in one of these buckets:

running on macOS/Linux/WSL2
using a slightly different install path
not hitting the same Windows/network/npm quirks

#

or they just leave the gateway running, so they never notice boot time much

So I would not read this as “you did something wrong”.
It looks more like your Windows environment is triggering edge cases that others are not hitting.

That’s exactly why I keep pointing at WSL2. It moves you onto a path that is closer to what tends to behave well.

If you want, I can give you the cleanest WSL2 migration path from your current setup so you do not have to guess.

summer sand Apr 15, 2026, 4:45 PM

#

can you tell me how to change these windows environment?

timid bobcatBOT Apr 15, 2026, 4:46 PM

#

Yes, the easiest way to “change the Windows environment” here is really:

install WSL2, then run OpenClaw inside Ubuntu instead of native Windows PowerShell.

Shortest path

1. Back up your current stuff
Keep these safe:

C:\Users\bhupa\.openclaw\openclaw.json
C:\Users\bhupa\.openclaw\workspace

2. Install WSL2 + Ubuntu
Open PowerShell as Administrator:

#

wsl --install -d Ubuntu-24.04

Reboot if Windows asks.

3. Open Ubuntu and enable systemd
In the Ubuntu terminal:

sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

Then back in PowerShell:

#

wsl --shutdown

Open Ubuntu again and verify:

systemctl --user status

4. Install OpenClaw inside WSL
Inside Ubuntu:

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

#

5. Bring over only what you need
You have two choices:

cleaner: rerun onboarding and re-enter your config/channel
faster: copy your config/workspace from Windows into WSL

Windows files are visible inside WSL under /mnt/c/...

For example:

mkdir -p ~/.openclaw
cp /mnt/c/Users/bhupa/.openclaw/openclaw.json ~/.openclaw/openclaw.json
mkdir -p ~/.openclaw/workspace
cp -r /mnt/c/Users/bhupa/.openclaw/workspace/* ~/.openclaw/workspace/

#

Important

After this, use Ubuntu/WSL for OpenClaw commands, not normal Windows PowerShell.

Docs:

If you want, next I can give you the safest migration version so you don’t accidentally copy over the bad state from Windows.

summer sand Apr 16, 2026, 10:44 AM

#

curl -fsSL https://openclaw.ai/install.sh | bash
openclaw onboard --install-daemon

🦞 OpenClaw Installer
If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

✓ Detected: linux

Install plan
OS: linux
Install method: npm
Requested version: latest
· Existing OpenClaw installation detected, upgrading

[1/3] Preparing environment
· Node.js not found, installing it now
· Installing Node.js via NodeSource
· Installing Linux build tools (make/g++/cmake/python3)

is this correct?

timid bobcatBOT Apr 16, 2026, 10:44 AM

#

Yes, that looks correct 👍

Inside WSL2, OpenClaw should detect Linux, and this part is normal:

Detected: linux
Node.js not found, installing it now
Installing Node.js via NodeSource
Installing Linux build tools (make/g++/cmake/python3)

That is exactly what I’d expect on a fresh Ubuntu/WSL setup.

A couple quick notes:

Existing OpenClaw installation detected means inside WSL, not your old Windows install
the build tools are normal, some deps/native packages need them
let the installer finish first, then run:

#

openclaw onboard --install-daemon

So yes, you’re on the right path.

If the next step throws anything weird, paste the next chunk and I’ll help you through it.

summer sand Apr 16, 2026, 10:46 AM

#

it doesn't show anything next for a while

timid bobcatBOT Apr 16, 2026, 10:46 AM

#

That can happen, especially on a fresh WSL install.

The NodeSource + apt/build-tools step can sit quietly for a bit while it is installing packages in the background.

I’d do this

give it 3 to 5 minutes first
if it is still silent after that, open another WSL terminal and run:

ps -ef | grep -E 'apt|dpkg|install.sh|node' | grep -v grep

If you see apt / dpkg running, it is probably still working.

If it stays silent for 10+ minutes

Then I’d stop it with:

#

Ctrl+C

and paste the last output plus the result of that ps command here.

So short version: a few minutes of silence here is not automatically bad.
If you want, send the ps output and I’ll tell you whether it is genuinely stuck.

summer sand Apr 16, 2026, 10:49 AM

#

/mnt/c/Users/bhupa/AppData/Roaming/npm/openclaw: 15: exec: node: not found

timid bobcatBOT Apr 16, 2026, 10:49 AM

#

Aha, that explains it.

WSL is trying to run your old Windows openclaw launcher here:

/mnt/c/Users/bhupa/AppData/Roaming/npm/openclaw

That is the wrong one for WSL.

It is basically saying:

“I found the Windows openclaw script on your PATH”
“but inside WSL/Linux I don’t have the matching node for that Windows shim”

What this means

You should not use the /mnt/c/.../npm/openclaw one from inside WSL.

#

You want the Linux-installed openclaw instead.

Check this in WSL

Run:

type -a openclaw
node --version
npm --version

What I expect

If type -a openclaw shows something under:

/mnt/c/Users/bhupa/AppData/Roaming/npm/openclaw

#

then WSL is still picking the Windows one.

Easiest fix

Close the Ubuntu/WSL terminal
Open a fresh WSL terminal
Re-run:

curl -fsSL https://openclaw.ai/install.sh | bash

After it finishes, run:

hash -r
type -a openclaw

#

You want openclaw to resolve to a Linux path, not /mnt/c/....

Important

From inside WSL, do not use the Windows npm global install.

If you paste the output of:

type -a openclaw
node --version
npm --version

I can tell you exactly what WSL is seeing.

summer sand Apr 16, 2026, 10:51 AM

#

openclaw is /mnt/c/Users/USER/AppData/Roaming/npm/openclaw
node: command not found
11.6.2

timid bobcatBOT Apr 16, 2026, 10:51 AM

#

Yep, that confirms it.

Your WSL shell is still using the Windows openclaw, and probably the Windows npm too.
That is why this is broken.

openclaw → /mnt/c/.../AppData/Roaming/npm/openclaw ❌
node → missing in WSL ❌
npm 11.6.2 is likely the Windows one too

Fix it in the current WSL shell

Run this first:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
hash -r
type -a openclaw || true

#

type -a npm || true
type -a node || true

After that, rerun the installer:

curl -fsSL https://openclaw.ai/install.sh | bash

Then verify

When it finishes, run:

hash -r

#

type -a openclaw
node --version
npm --version

What we want

node --version should work
openclaw should not point to /mnt/c/...

So the real problem right now is not OpenClaw itself, it is that WSL PATH is polluted by the Windows npm path.

If you want, paste the output after running the export PATH=... block and I’ll check it with you.

summer sand Apr 16, 2026, 10:53 AM

#

-bash: type: openclaw: not found

timid bobcatBOT Apr 16, 2026, 10:53 AM

#

Perfect, that is actually good news.

It means the bad Windows openclaw shim is no longer on your PATH.

Now do this

Check whether Linux Node is present:

node --version
npm --version

If `node` is still missing

Run the installer again:

#

curl -fsSL https://openclaw.ai/install.sh | bash

After it finishes

Run:

hash -r
openclaw --version

If that works, then you are finally using the real WSL/Linux OpenClaw.

So this is progress, not a new problem 🙂

If you want, paste the output of:

#

node --version
npm --version

next.

summer sand Apr 16, 2026, 11:02 AM

#

node --version
npm --version
node: command not found
Command 'npm' not found, did you mean:
command 'nm' from deb binutils (2.42-4ubuntu2.8)
Try: sudo apt install <deb name>

timid bobcatBOT Apr 16, 2026, 11:02 AM

#

Good, that means your WSL shell is now clean.
Right now the problem is simply: Node and npm are not installed in WSL yet.

Next step

Run the installer again in this clean shell:

export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
curl -fsSL https://openclaw.ai/install.sh | bash

That should install:

Node
npm
OpenClaw

#

After it finishes

Run:

node --version
npm --version
openclaw --version

If it hangs again

Then we know the problem is specifically the Node install step inside WSL, and we can debug that next.

You’re actually in a much better place now than before, because the Windows PATH contamination is gone.

summer sand Apr 16, 2026, 11:07 AM

#

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-backports/restricted/dep11/Components-amd64.yml.xz Hash Sum mismatch
Hashes of expected file:
- Filesize:216 [weak]
- SHA256:951136adb5a979e500e70c2cd41e23ffcc4f2fd9de70dbc5dd0f04485687490d
- SHA1:484537f43a6a78f72c13c1b8d82274518abd7d8c [weak]
- MD5Sum:4af6047fe59d6b35bbc7a38230943617 [weak]
Hashes of received file:
- SHA256:31304fb80033939499007b05a600b1f337aa93f107788051376b5f4987766f91
- SHA1:25aa524c74539864f6fdab2f58dd6acfd08a8bf0 [weak]
- MD5Sum:69ace3df561913242dfa8055eff5f240 [weak]
- Filesize:216 [weak]
Last modification reported: Wed, 15 Apr 2026 22:01:54 +0000
Release file created at: Thu, 16 Apr 2026 10:20:52 +0000
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/multiverse/dep11/Components-amd64.yml.xz Hash Sum mismatch
Hashes of expected file:
- Filesize:208 [weak]
- SHA256:bc4e32623745fff6f67ace8620911ac32e7b123e8401288e7a2164a570668214
- SHA1:5a99a0f931a7a1c2ec881e3308b9f7dde42b1012 [weak]
- MD5Sum:fa1ac9bedbc67001920b800a7d42b1ed [weak]
Hashes of received file:
- SHA256:86319127e986f175b8164ef2c51cd628ffd7d11b06359a096aa40133daf07ef5
- SHA1:8d7241a6101410b84e317aa276ce4a11bb26718e [weak]
- MD5Sum:bf3dbcd500b9a62d08e8b0fbb7a69a3c [weak]
- Filesize:208 [weak]
Last modification reported: Wed, 15 Apr 2026 22:26:04 +0000
Release file created at: Thu, 16 Apr 2026 10:19:21 +0000
E: Some index files failed to download. They have been ignored, or old ones used instead.

timid bobcatBOT Apr 16, 2026, 11:08 AM

#

That error is not OpenClaw, it is an Ubuntu apt mirror/cache problem.

Hash Sum mismatch usually means the Ubuntu mirror metadata changed while your machine was downloading package indexes.

Fix

In WSL, run:

sudo apt clean
sudo rm -rf /var/lib/apt/lists/*
sudo apt update

If apt update succeeds after that, rerun:

#

curl -fsSL https://openclaw.ai/install.sh | bash

If it still fails

Wait 5 to 10 minutes and try again. Sometimes the Ubuntu mirrors are mid-sync and it clears on its own.

So short version:

not your OpenClaw config
not your Discord setup
just Ubuntu package index mismatch

If you want, paste the result of sudo apt update after those commands and I’ll check it.

summer sand Apr 16, 2026, 11:24 AM

#

✗ Updating package index failed — re-run with --verbose for details
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/main/dep11/Components-amd64.yml.xz File has unexpected size (21528 != 21536). Mirror sync in progress? [IP: 91.189.91.81 80]
Hashes of expected file:
- Filesize:21536 [weak]
- SHA256:3e08e9582239b43491ef8ca4e7d43a24fa7e129d3e6120820503122088ba351e
- SHA1:be2b41261c74be6430e06e47387bf6d0b83c7f23 [weak]
- MD5Sum:5bd773531cbf27acd867b9aaef4ffbc8 [weak]
Release file created at: Thu, 16 Apr 2026 10:19:21 +0000
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/universe/dep11/Components-amd64.yml.xz
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/restricted/dep11/Components-amd64.yml.xz
E: Failed to fetch http://security.ubuntu.com/ubuntu/dists/noble-security/multiverse/dep11/Components-amd64.yml.xz
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-backports/main/dep11/Components-amd64.yml.xz File has unexpected size (7368 != 7344). Mirror sync in progress? [IP: 91.189.91.81 80]
Hashes of expected file:
- Filesize:7344 [weak]
- SHA256:0b6ff63e92a3ad3213ae3973a6af10219a2e0ac68bd333cf12cdbe0aafb28bf7
- SHA1:016e01ffc816bfb15ef86440dec1c7ce7dbe842e [weak]
- MD5Sum:570199dc615cdf85883b26eee887da94 [weak]
Release file created at: Thu, 16 Apr 2026 10:20:52 +0000
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-backports/universe/dep11/Components-amd64.yml.xz
E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-backports/restricted/dep11/Components-amd64.yml.xz
E: Some index files failed to download. They have been ignored, or old ones used instead.

timid bobcatBOT Apr 16, 2026, 11:24 AM

#

Yep, this is still the Ubuntu mirror, not OpenClaw.

The key clue is right in the error:

Mirror sync in progress?

and all the failures are on dep11 metadata from Ubuntu mirrors.

What I recommend

Just wait a bit and retry.

Try again in 15 to 30 minutes:

#

sudo apt clean
sudo rm -rf /var/lib/apt/lists/*
sudo apt update

If that succeeds, then rerun the OpenClaw installer.

Why

Ubuntu’s mirror metadata is temporarily inconsistent right now, so your machine is seeing files whose size/hash does not match the release file yet.

That is annoying, but it is a mirror timing problem, not something you broke.

If it still fails later

If it is still failing after ~1 hour, then it is worth switching to a different Ubuntu mirror, and I can walk you through that.

So for now, I would not keep fighting OpenClaw.

#

I would wait a bit, rerun apt update, and only escalate to mirror switching if it keeps happening.

summer sand Apr 16, 2026, 11:32 AM

#

E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/noble-updates/multiverse/binary-amd64/Packages.xz File has unexpected size (32480 != 32476). Mirror sync in progress? [IP: 91.189.91.81 80]
Hashes of expected file:
- Filesize:32476 [weak]
- SHA256:cbc6d5dd2398b0b502917ceadd77800cbd974264cdd1fb149760dec173aadf23
- SHA1:7121e2f52b692f0456c9ac58e9ae7f05178e1ca1 [weak]
- MD5Sum:c061c7e71a74534f19ea3d219be89209 [weak]
Release file created at: Thu, 16 Apr 2026 10:19:50 +0000
E: Some index files failed to download. They have been ignored, or old ones used instead.

timid bobcatBOT Apr 16, 2026, 11:32 AM

#

Still the same Ubuntu mirror issue, unfortunately.

And now it is hitting a real package index file:

binary-amd64/Packages.xz

so I would stop retrying the installer for now.
This is not an OpenClaw problem.

My recommendation

wait 30 to 60 minutes
then run:

#

sudo apt clean
sudo rm -rf /var/lib/apt/lists/*
sudo apt update

only after apt update succeeds, rerun the OpenClaw installer

If it still fails after that

Then I would switch Ubuntu mirrors.

If you want, when you’re ready, paste:

cat /etc/apt/sources.list.d/ubuntu.sources

#

and I’ll help you change it safely.

So short version: still mirror sync, now affecting package indexes too. Don’t fight OpenClaw until apt is healthy.

summer sand Apr 16, 2026, 11:33 AM

#

is there anyways I can uninstall everything, I'm okay with the old windows now

timid bobcatBOT Apr 16, 2026, 11:33 AM

#

Yes, absolutely.

And the good news is: you do not need to touch your old Windows OpenClaw install.
The WSL attempt is separate.

Easiest option

If you just want to give up on WSL for now, you can simply close WSL and keep using the old Windows setup.

If you want to remove the WSL Ubuntu environment

Open PowerShell and run:

wsl --list --verbose

Find the distro name, then remove it with:

#

wsl --unregister Ubuntu-24.04

Replace Ubuntu-24.04 with whatever your distro name is.

Important

wsl --unregister permanently deletes everything inside that WSL distro.

But it does not remove your old Windows OpenClaw install.

So my recommendation

if you are okay with Windows again, just stop here
if you want cleanup, unregister the Ubuntu distro

If you want, paste the output of:

#

wsl --list --verbose

and I’ll tell you the exact distro name to remove.

summer sand Apr 16, 2026, 11:35 AM

#

wsl --list --verbose
Command 'wsl' not found, but can be installed with:
sudo apt install wsl

timid bobcatBOT Apr 16, 2026, 11:36 AM

#

Yep, that means you ran it inside Ubuntu/WSL.

wsl --list --verbose is a Windows PowerShell command, not a Linux command.

Do this instead

Close the Ubuntu/WSL terminal
Open Windows PowerShell
Run:

wsl --list --verbose

Then remove the distro with:

#

wsl --unregister Ubuntu-24.04

or whatever exact distro name it shows.

So:

inside Ubuntu → Linux commands
inside Windows PowerShell → wsl ... commands

If you want, paste the PowerShell output and I’ll tell you the exact uninstall command.

summer sand Apr 16, 2026, 11:39 AM

#

PS C:\WINDOWS\system32> wsl --list --verbose
NAME STATE VERSION

docker-desktop Stopped 2
Ubuntu-24.04 Stopped 2
PS C:\WINDOWS\system32> wsl --list --verbose
NAME STATE VERSION
docker-desktop Stopped 2
Ubuntu-24.04 Stopped 2
PS C:\WINDOWS\system32> wsl --unregister Ubuntu-24.04
Unregistering.
The operation completed successfully.

timid bobcatBOT Apr 16, 2026, 11:39 AM

#

Nice, that worked.

Ubuntu-24.04 is gone now, and docker-desktop was left alone, which is what we wanted.

So you are basically back to:

old Windows OpenClaw install still there
WSL Ubuntu test environment removed

If you want, we can just continue from the Windows setup now and keep it simple.

summer sand Apr 16, 2026, 11:40 AM

#

ok I'll do windows setup

timid bobcatBOT Apr 16, 2026, 11:40 AM

#

Makes sense.

If I were you, on Windows I’d do this:

keep the config simple
avoid restarting the gateway too often
if you want the easiest day-to-day chat channel, use Telegram

Telegram is still the fastest/easiest one to wire up:
https://docs.openclaw.ai/channels/telegram

If you want, next I can help you with either:

cleaning the Windows config, or
setting up Telegram on the Windows install

summer sand Apr 16, 2026, 11:41 AM

#

I want tocleaning the Windows config

timid bobcatBOT Apr 16, 2026, 11:41 AM

#

Yep. For a leaner Windows config, I’d simplify yours to this shape:

{
  "gateway": {
    "mode": "local",
    "auth": {
      "mode": "token",
      "token": "TOKEN"
    },
    "port": 18789,
    "bind": "loopback",
    "tailscale": {
      "mode": "off",
      "resetOnExit": false
    },

#

    "nodes": {
      "denyCommands": [
        "camera.snap",
        "camera.clip",
        "screen.record",
        "contacts.add",
        "calendar.add",
        "reminders.add",
        "sms.send",
        "sms.search"
      ]
    }
  },
  "discovery": {
    "mdns": {

#

      "mode": "off"
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "tools": {
    "profile": "coding",
    "web": {
      "search": {
        "provider": "searxng"
      }
    }
  },
  "channels": {

#

    "discord": {
      "enabled": true,
      "token": "TOKEN",
      "groupPolicy": "open",
      "dmPolicy": "allowlist",
      "dm": {
        "enabled": true
      },
      "allowFrom": [
        "920199943136874506"
      ]
    }
  },
  "hooks": {
    "internal": {

#

      "enabled": true,
      "entries": {
        "command-logger": {
          "enabled": true
        },
        "session-memory": {
          "enabled": true
        }
      }
    }
  },
  "plugins": {
    "entries": {
      "searxng": {
        "enabled": true,

#

        "config": {
          "webSearch": {
            "baseUrl": "http://localhost:8080"
          }
        }
      },
      "browser": {
        "enabled": false
      },
      "acpx": {
        "enabled": false
      }
    }
  }
}

#

Main cleanup changes

add:

"discovery": { "mdns": { "mode": "off" } }

use:
```
"acpx": { "enabled": false }
```
instead of stale acp
keep browser off
remove empty/unneeded sections like skills: {}
wizard and meta can be left alone or regenerated by OpenClaw, they are not important for your manual cleanup

Important

Remove this stale part if it is still there:

#

"acp": {
  "enabled": false
}

That one was wrong for the plugin system.

After saving, restart the gateway and test again.

If you want, I can also give you the smallest diff-only version so you do not have to replace the whole file.

summer sand Apr 16, 2026, 11:45 AM

#

18:44:00 [gateway] loading configuration…
18:44:01 [gateway] resolving authentication…
18:44:01 [gateway] starting...
18:44:26 [gateway] starting HTTP server...
18:44:26 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
18:44:26 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:44:27 [gateway] agent model:
18:44:27 [gateway] ready (4 plugins: device-pair, discord, phone-control, talk-voice; 25.3s)
18:44:27 [gateway] log file: \tmp\openclaw\openclaw-2026-04-16.log
18:44:27 [gateway] starting channels and sidecars...
18:44:28 [hooks] loaded 4 internal hook handlers
18:44:54 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
18:45:05 [heartbeat] started
18:45:05 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
18:45:05 [discord] [default] starting provider (@OpenClawy)
18:45:05 [discord] users resolved: 920199943136874506
18:45:08 [discord] client initialized as 1483445847722033315 (OpenClawy); awaiting gateway readiness

Is this still take a long time?

timid bobcatBOT Apr 16, 2026, 11:46 AM

#

Yes, I’d still call that slow.

Roughly:

18:44:01 starting
18:45:08 Discord client initialized

So you are still at about 1 minute end-to-end.

The good part

Your config is definitely cleaner now:

stuck bootstrap is gone
Bonjour/mDNS noise is gone
ACP/browser noise is gone

The bad part

#

The main delay is still there:

about 25 seconds just to get the gateway ready
then another delay before Discord starts

plus the recurring:

[model-pricing] pricing bootstrap failed: TimeoutError

So my honest answer is:

better / cleaner? yes
actually fast now? no

At this point, I don’t think there is an obvious config cleanup left that will magically make Windows boot fast.

If you want, the next realistic choices are:

#

accept it and keep the gateway running
switch your day-to-day chat to Telegram
file a GitHub issue with these cleaned logs, because this now looks like native Windows startup behavior / bug territory

GitHub issues:
https://github.com/openclaw/openclaw/issues

summer sand Apr 16, 2026, 11:48 AM

#

can you tell me how to file the issue?

timid bobcatBOT Apr 16, 2026, 11:48 AM

#

Yep. I can’t file it for you, but I can make it easy.

Where to file it

Go here:

https://github.com/openclaw/openclaw/issues

Click New issue and choose the bug report option if it shows one.

Good issue title

Windows: Gateway startup takes ~60s before Discord comes online

Paste this as the body

### Version

#

openclaw 2026.4.14

### OS
Windows 10.0.26200 x64

### Channel
Discord

### Problem
On native Windows, the gateway takes about 1 minute before the Discord bot is effectively online.

### What I expected
Gateway/Discord startup should be much faster.

### What actually happens

#

Recent startup log:

18:44:00 [gateway] loading configuration…
18:44:01 [gateway] resolving authentication…
18:44:01 [gateway] starting...
18:44:26 [gateway] starting HTTP server...
18:44:26 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/
18:44:26 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
18:44:27 [gateway] agent model:
18:44:27 [gateway] ready (4 plugins: device-pair, discord, phone-control, talk-voice; 25.3s)
18:44:27 [gateway] log file: \tmp\openclaw\openclaw-2026-04-16.log
18:44:27 [gateway] starting channels and sidecars...
18:44:28 [hooks] loaded 4 internal hook handlers
18:44:54 [model-pricing] pricing bootstrap failed: TimeoutError: The operation was aborted due to timeout
18:45:05 [heartbeat] started

#

18:45:05 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
18:45:05 [discord] [default] starting provider (@OpenClawy)
18:45:05 [discord] users resolved: 920199943136874506
18:45:08 [discord] client initialized as 1483445847722033315 (OpenClawy); awaiting gateway readiness

### Things I already tried
- fixed stuck bootstrap state (`bootstrapping` is now 0)
- disabled browser plugin
- disabled ACP/acpx
- turned off mDNS / Bonjour discovery
- cleaned stale `plugins.entries.acp` config
- issue still remains on native Windows

### Extra notes
This seems to be mostly a native Windows startup issue, not a Discord token/config issue.

#

Small tip

If GitHub asks for repro steps, add this:

1. Start the gateway on native Windows
2. Watch logs during startup
3. Observe ~25s to gateway ready and ~60s until Discord startup completes

If you want, after you post it, send me the issue link and I can help you tighten the wording a bit.

summer sand Apr 16, 2026, 12:25 PM

#

http://127.0.0.1:18789/__openclaw__/canvas/
I opened this link and it doesn't show a canvas, it showed this error: {"error":{"message":"Unauthorized","type":"unauthorized"}}

timid bobcatBOT Apr 16, 2026, 12:25 PM

#

That is normal.

/__openclaw__/canvas/ is not a public page you open directly.
It is an internal, auth-protected endpoint, so with:

"gateway": {
  "auth": {
    "mode": "token"
  }
}

getting:

#

{"error":{"message":"Unauthorized","type":"unauthorized"}}

is expected.

What to open instead

Use:

http://127.0.0.1:18789/

or run:

#

openclaw dashboard

If the dashboard asks for auth, paste your configured gateway token.

So short version:

/__openclaw__/canvas/ → internal endpoint, auth required
http://127.0.0.1:18789/ → the actual dashboard entry point

Docs:

summer sand Apr 16, 2026, 12:30 PM

#

Failed to install bundled plugin runtime deps: Error: npm install failed

I ran openclaw doctor --fix and this printed

timid bobcatBOT Apr 16, 2026, 12:31 PM

#

Yep, that is the same bundled plugin deps problem from earlier.

In your case, doctor was trying to install:

@discordjs/opus

and npm failed again.

What that means

@discordjs/opus is mainly a Discord voice/audio runtime dependency.
So if you are only using normal text chat, this is usually not the main thing to worry about.

My honest recommendation

For your current startup issue, I would not chase this first.

#

Why:

it is a separate npm/native-module install problem
on Windows, @discordjs/opus install failures are not unusual
your main slow-start problem existed even before this

So short version

openclaw doctor --fix tried to auto-install a missing Discord runtime dep
npm failed
that is annoying, but it is probably voice-related, not the core reason your text bot starts slowly

If you are not using Discord voice, I would ignore this warning for now.

If you do want to fix it later, send me the full lines above the error again and I can help you figure out whether it is worth dealing with.

summer sand Apr 16, 2026, 12:35 PM

#

openclaw gateway start
Invalid config at C:\Users\USER.openclaw\openclaw.json:\n- gateway.bind: Invalid input (allowed: "auto", "lan", "loopback", "custom", "tailnet")

🦞 OpenClaw 2026.4.14 (323493f) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

Config invalid
File: ~.openclaw\openclaw.json
Problem:

gateway.bind: Invalid input (allowed: "auto", "lan", "loopback", "custom", "tailnet")

Run: openclaw doctor --fix
Gateway aborted: config is invalid.
gateway.bind: Invalid input (allowed: "auto", "lan", "loopback", "custom", "tailnet")
Fix the config and retry, or run "openclaw doctor" to repair.

What is this?? it happen when I ran openclaw gateway start

timid bobcatBOT Apr 16, 2026, 12:36 PM

#

That means your config file currently has an invalid value for gateway.bind.

gateway.bind only accepts:

"auto", "lan", "loopback", "custom", "tailnet"

For your setup, the safe local value is usually:

"bind": "loopback"

Most likely fix

Open C:\Users\USER\.openclaw\openclaw.json and make sure your gateway block has:

#

"gateway": {
  "mode": "local",
  "bind": "loopback"
}

Important

discovery.mdns.mode: "off" is fine.
That is separate from gateway.bind.

So do not set:

"bind": "off"

#Gateway start very slow

Quick test

Safe next step

One more useful detail

Best way to narrow it down

Safe repair step

If you want deeper diagnosis

What I’d do next

My recommendation

If you do not use the browser tool

If you do not use ACP sessions / Codex / Claude Code thread bindings

Also worth doing

Why I’m pointing here

Why people use it for OpenClaw

Basic setup

Important mindset

Docs

What I’d do next

Honest recommendation

So check this file

If you already finished first-run setup

Why this matters

What I need from you

1. plugins.entries.acp is stale config

2. @discordjs/opus is missing

Most important point

Short version

Next step

My read right now

My recommendation

Option 1, best first test: turn off Bonjour/mDNS

Option 2, if you do not use ACP at all: disable the real plugin, acpx

Also worth noting

Short version

I would change it like this

And remove this stale bit

Why

What to do after

My honest read

What I’d recommend now

My honest recommendation

If you do reinstall

Best use of your time

If your goal is fix the slow boot

If your goal is use an easier channel

My recommendation

Shortest path

Important

I’d do this

If it stays silent for 10+ minutes

What this means

Check this in WSL

What I expect

Easiest fix

Important

Fix it in the current WSL shell

Then verify

What we want

Now do this

If node is still missing

After it finishes

Next step

After it finishes

If it hangs again

Fix

If it still fails

What I recommend

Why

If it still fails later

My recommendation

If it still fails after that

Easiest option

If you want to remove the WSL Ubuntu environment

Important

So my recommendation

Do this instead

Main cleanup changes

Important

The good part

The bad part

1. `plugins.entries.acp` is stale config

2. `@discordjs/opus` is missing

Option 2, if you do not use ACP at all: disable the real plugin, `acpx`

If `node` is still missing