My openclaw bot isnt starting on discord even when I ask it to restart in the dashboard | Friends of the Crustacean 🦞🤝 | Page 1

dreamy turtle May 11, 2026, 8:59 PM

#

h

remote fieldBOT May 11, 2026, 8:59 PM

#

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

primal windBOT May 11, 2026, 8:59 PM

#

Hey — I can help, but I’ll need a little more than “h” 😄

First thing: what OpenClaw version are you on?

openclaw --version
openclaw status --all
openclaw gateway status

Please paste the output from those. openclaw status --all is meant to be shareable and redacts tokens.

Also: when you say “restart in the dashboard,” do you mean the Gateway restarts but the Discord bot still doesn’t respond, or the restart itself fails?

Docs while we debug: https://docs.openclaw.ai/help/faq

dreamy turtle May 11, 2026, 9:01 PM

#

Gateway restart attempts (tail): C:\Users\jabuc.openclaw\logs\gateway-restart.log
[Sat 05/09/2026 13:57:32.24] openclaw restart log initialized
[Sat 05/09/2026 13:57:32.24] openclaw restart attempt source=windows-task-handoff target="OpenClaw Gateway"
[Sat 05/09/2026 13:57:34.68] openclaw restart finished source=windows-task-handoff
[Sun 05/10/2026 11:15:25.25] openclaw restart log initialized
[Sun 05/10/2026 11:15:25.27] openclaw restart attempt source=windows-task-handoff target="OpenClaw Gateway"
[Sun 05/10/2026 11:15:27.70] openclaw restart finished source=windows-task-handoff
! Channel issues skipped (gateway unreachable)

primal windBOT May 11, 2026, 9:01 PM

#

That tail says the Windows handoff finished, but the important bit is gateway unreachable — so this probably isn’t a Discord-bot problem yet. The gateway isn’t reachable after restart, so channel checks can’t run.

Please run these in PowerShell/CMD on that Windows machine and paste the output:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw gateway probe
openclaw logs --tail 80

If openclaw logs --tail 80 doesn’t work on your version, use:

type "%USERPROFILE%\.openclaw\logs\gateway.log"

#

or paste the newest log file from:

dir /od "%USERPROFILE%\.openclaw\logs"

What I’m looking for: whether the service/task is actually running, what URL/port the CLI is probing, and the first fatal error in the gateway log. Once the gateway is reachable, then we can check Discord with openclaw channels status --probe.

Docs: https://docs.openclaw.ai/help/troubleshooting

dreamy turtle May 11, 2026, 9:02 PM

#

Channels
+----------+---------+--------+----------------------------------------------------------------------------------------+
| Channel | Enabled | State | Detail |
+----------+---------+--------+----------------------------------------------------------------------------------------+
| Discord | ON | OK | token config (sha256:eee9d985 · len 72) · accounts 1/1 |
+----------+---------+--------+----------------------------------------------------------------------------------------+

primal windBOT May 11, 2026, 9:03 PM

#

Good, that narrows it down: your Discord token config looks OK. The blocker is earlier:

Gateway service | Scheduled Task installed · registered · stopped (state Queued ... treating as not running.)

So the dashboard restart is handing off to Windows Task Scheduler, but the Gateway task isn’t actually running afterward.

Next best step: run the Gateway in the foreground so we can see the real startup error:

openclaw --version
openclaw gateway run

Leave that window open. If it prints an error, paste the first fatal/error lines here. If it stays running, then in another PowerShell run:

#

openclaw gateway probe
openclaw channels status --probe

If foreground works, reinstall the Windows scheduled task:

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

Also note 1 bootstrapping · 0 active: after the gateway is reachable, the agent may still need to finish first-run bootstrapping before it responds normally.

Docs: https://docs.openclaw.ai/platforms/windows and https://docs.openclaw.ai/gateway

dreamy turtle May 11, 2026, 9:06 PM

#

it started typing but didnt and i got this 16:06:00 [diagnostic] liveness warning: reasons=event_loop_delay interval=40s eventLoopDelayP99Ms=1110.4 eventLoopDelayMaxMs=18203.3 eventLoopUtilization=0.877 cpuCoreRatio=0.818 active=1 waiting=0 queued=1 phase=channels.discord.start-account recentPhases=sidecars.restart-sentinel:0ms,sidecars.subagent-recovery:6ms,sidecars.main-session-recovery:10ms,post-attach.update-sentinel:0ms,sidecars.session-locks:43ms,post-ready.maintenance:464ms work=[active=agent:main:discord:channel:1502713886695227564(processing,q=1,age=33s) queued=agent:main:discord:channel:1502713886695227564(processing,q=1,age=33s)]
16:06:09 [ws] ⇄ res ✓ sessions.list 692ms conn=5fd5ec38…ccdc id=1dd18351…4ba4
16:06:09 [ws] ⇄ res ✗ sessions.resolve 4ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=0327b5ff…44f4 id=e5b7f7df…f87d
16:06:09 [ws] ⇄ res ✗ sessions.resolve 7ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=dbc3f050…b47c id=bbbd38b4…b212

primal windBOT May 11, 2026, 9:07 PM

#

That’s progress — the gateway is alive now. This log means Discord received the message and OpenClaw started processing it, but the agent run got stuck/slow:

active=agent:main:discord:channel:1502713886695227564(processing...)

The sessions.resolve No session found: current lines are probably dashboard/UI noise, not the main failure. The scary part is the liveness warning: event loop max delay 18s and utilization 0.877, while the Discord account is starting. That usually means the gateway is overloaded or blocked during startup/agent processing.

Please grab the next useful logs around the actual agent failure:

openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw logs --tail 200

If it’s still stuck, try a clean gateway restart from the CLI, then send one simple test message:

#

openclaw gateway restart
openclaw logs --follow

Then message the bot with just: hi

Also: your status earlier said 1 bootstrapping · 0 active. If the log mentions BOOTSTRAP.md or bootstrapping repeatedly, paste that part too — that can keep the first run from completing.

dreamy turtle May 11, 2026, 9:08 PM

#

🦞 OpenClaw 2026.5.7 (eeef486) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

|
o
Gateway reachable.
Gateway event loop degraded: reasons=event_loop_utilization,cpu eventLoopDelayMaxMs=0 eventLoopUtilization=1 cpuCoreRatio=0.943

Discord default: enabled, configured, running, connected, in:3m ago, bot:@Retep, token:config, intents:content=limited, works, audit ok

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

primal windBOT May 11, 2026, 9:08 PM

#

Nice, that’s a much better state: Gateway is reachable and Discord is connected/audited OK. So the bot is starting now — the remaining issue is the agent run is pegging the gateway CPU/event loop and not finishing its reply.

Two likely causes from your earlier output:

1 bootstrapping · 0 active — first-run bootstrap may be stuck.
Model/tool call is hanging or looping — gateway is at eventLoopUtilization=1 / CPU 0.943.

Please paste:

openclaw logs --tail 200
openclaw status --deep
openclaw models status

Look especially for lines mentioning bootstrap, BOOTSTRAP.md, model, rate_limit, tool, or repeated errors.

#

Quick test: message your bot something tiny like hi and watch:

openclaw logs --follow

If it gets stuck on bootstrapping, the pragmatic fix is usually to finish/reset the bootstrap state or remove the leftover BOOTSTRAP.md from the agent workspace, then restart. But don’t delete anything yet — let’s confirm from the logs first.

dreamy turtle May 11, 2026, 9:10 PM

#

Summary: 1 critical · 5 warn · 1 info
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - openrouter/meta-llama/llama-3.1-8b-instruct (8B) @ agents.defaults.model.primary (unsafe; sandbox=off; web=[off]) No w…
Fix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"]).
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
WARN Control UI insecure auth toggle enabled
gateway.controlUi.allowInsecureAuth=true does not bypass secure context or device identity checks; only dangerouslyDisableDeviceAuth disables Control UI device…
Fix: Disable it or switch to HTTPS (Tailscale Serve) or localhost.
WARN Insecure or dangerous config flags enabled
Detected 1 enabled flag(s): gateway.controlUi.allowInsecureAuth=true.
Fix: Disable these flags when not actively debugging, or keep deployment scoped to trusted/local-only networks.
WARN Potential multi-user setup detected (personal-assistant model warning)
Heuristic signals indicate this gateway may be reachable by multiple users: - channels.discord.groupPolicy="allowlist" with configured group targets No unguard…
Fix: If users may be mutually untrusted, split trust boundaries (separate gateways + credentials, ideally separate OS users/hosts). If you intentionally run shared-user access, set agents.defaults.sandbox.mode="all", keep tools.fs.workspaceOnly=true, deny runtime/fs/web tools unless required, and keep personal/private identities + credentials off that runtime.
WARN Plugin index includes unpinned npm specs
Unpinned plugin index install records: - discord

primal windBOT May 11, 2026, 9:10 PM

#

That audit output is useful. The critical item is the one I’d fix first:

You’re running the Discord agent on a very small OpenRouter model. Even if it connects, that kind of model is often unreliable for OpenClaw agent runs — it can stall, fail tool/schema handling, or never produce a clean final reply. That matches “started typing but didn’t send.”

Best fix: switch the default agent model to a stronger tool-capable model via the model picker/onboarding, then restart:

openclaw onboard
openclaw gateway restart

Then test Discord with hi while watching:

openclaw logs --follow

#

If you intentionally want to keep that small model, follow the audit hardening instead:

openclaw config set agents.defaults.sandbox.mode all
openclaw config set tools.deny '["group:web","browser"]' --strict-json
openclaw gateway restart

But my recommendation is: don’t use the small model for Discord support/testing yet. First get a reliable model replying, then tune cost later.

The other warnings (trustedProxies, allowInsecureAuth, plugin pinning) are security/deployment cleanup. They’re important, but they’re probably not why the bot is stuck typing.

Docs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/gateway/sandboxing

dreamy turtle May 11, 2026, 9:13 PM

#

I understand this is personal-by-default and shared/multi-user use requires lock-down. Continue?
| Yes
|

Setup mode
| > QuickStart (Configure details later via openclaw configure.)
| Manual

primal windBOT May 11, 2026, 9:13 PM

#

Choose Yes, then QuickStart.

That’s the right path here: get the gateway + Discord agent into a known-good baseline first, then tune security/model details afterward with openclaw configure.

After QuickStart finishes, run:

openclaw gateway restart
openclaw status --all
openclaw channels status --probe

Then test the Discord bot with a tiny hi. If it still types forever, paste the latest openclaw logs --tail 200.

dreamy turtle May 11, 2026, 9:14 PM

#

Config handling
| > Use existing values
| Update values

primal windBOT May 11, 2026, 9:14 PM

#

Choose Update values.

The existing config is still using:

openrouter/meta-llama/llama-3.1-8b-instruct

That’s the small model that’s likely causing the “typing but never sends” behavior. Update the model to a stronger/reliable one during setup, then continue.

After it finishes:

openclaw gateway restart
openclaw status --all
openclaw channels status --probe

#

Then test the bot with hi.

dreamy turtle May 11, 2026, 9:14 PM

#

primal windBOT May 11, 2026, 9:15 PM

#

Pick the provider you actually have auth for, but for getting unstuck I’d choose one of the strong mainstream options:

Anthropic if you have a Claude API key or Claude CLI auth
Codex if you’re using OpenAI/Codex auth
Google if you have Gemini API auth

Avoid the tiny/cheap model providers for now — we want a reliable tool-capable baseline first.

If you’re not sure which one you have credentials for, choose Anthropic if available; it’s usually the smoothest path for OpenClaw agent/tool behavior. Then continue through auth, restart, and test:

openclaw gateway restart
openclaw channels status --probe

dreamy turtle May 11, 2026, 9:16 PM

#

Enter OpenRouter API key
| •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
|
o Model configured ---------------------+
| |
| Default model set to openrouter/auto |
| |
+----------------------------------------+
|

Default model
| > Keep current (openrouter/auto)
| Enter model manually
| Browse all models

primal windBOT May 11, 2026, 9:16 PM

#

Choose Keep current (openrouter/auto) for now.

That’s already much better than being pinned to the 8B Llama model — OpenRouter can route to a more capable model, and we’re trying to get you to a working baseline first.

After setup finishes, run:

openclaw gateway restart
openclaw status --all
openclaw channels status --probe

Then test Discord with hi. If it still types forever, we’ll switch from openrouter/auto to a specific stronger model via Browse all models or openclaw models set, but don’t complicate it yet.

dreamy turtle May 11, 2026, 9:16 PM

#

primal windBOT May 11, 2026, 9:17 PM

#

Select Discord (Bot API).

Since your Discord token was already detected as OK earlier, it may ask whether to keep/update the existing Discord config — choose keep existing unless you’re trying to replace the bot token.

After the wizard finishes:

openclaw gateway restart
openclaw status --all
openclaw channels status --probe

Then send the bot hi and see if it completes the reply this time.

dreamy turtle May 11, 2026, 9:17 PM

#

Discord already configured. What do you want to do?
| > Modify settings
| Skip (leave as-is)
—

primal windBOT May 11, 2026, 9:17 PM

#

Choose Skip (leave as-is).

Your Discord config already passed earlier (connected, works, audit ok), so we don’t want to accidentally change the bot token/settings. The thing we needed to fix was the model, and you’ve moved that to openrouter/auto.

After the wizard completes:

openclaw gateway restart
openclaw status --all
openclaw channels status --probe

Then test the bot with hi.

dreamy turtle May 11, 2026, 9:19 PM

#

it says setup canceled

primal windBOT May 11, 2026, 9:19 PM

#

No worries — that can happen if the wizard backs out at the channel step.

Check whether the model change still saved:

openclaw models status

If it says the default is openrouter/auto, you’re fine. Just do:

openclaw gateway restart
openclaw channels status --probe

If it still says openrouter/meta-llama/llama-3.1-8b-instruct, skip the wizard and set it directly:

#

openclaw models set openrouter/auto
openclaw gateway restart
openclaw models status
openclaw channels status --probe

Then test the Discord bot with hi.

dreamy turtle May 11, 2026, 9:20 PM

#

PS C:\Users\jabuc> openclaw gateway restart

🦞 OpenClaw 2026.5.7 (eeef486)
I autocomplete your thoughts—just slower and with more API calls.

Gateway restart failed: Error: gateway port 18789 is still busy before restart
Tip: openclaw gateway install
Tip: openclaw gateway
Tip: schtasks /Run /TN "OpenClaw Gateway"
PS C:\Users\jabuc>

primal windBOT May 11, 2026, 9:20 PM

#

That means something is already listening on port 18789 — most likely the foreground openclaw gateway run window from earlier is still running.

Do this first:

Find the PowerShell/CMD window where you ran openclaw gateway run
Press Ctrl+C in that window
Then run:

openclaw gateway restart
openclaw gateway status

If you can’t find the window/process, identify what owns the port:

#

Get-NetTCPConnection -LocalPort 18789 | Select-Object OwningProcess,State,LocalAddress,LocalPort
Get-Process -Id <OwningProcess>

If it’s node.exe / openclaw, close that process/window, then retry the restart.

Also check the model after the canceled setup:

openclaw models status

If it still shows the 8B Llama model, run:

#

openclaw models set openrouter/auto

Then restart once the port is free.

dreamy turtle May 11, 2026, 9:28 PM

#

PS C:\Users\jabuc> openclaw gateway restart

🦞 OpenClaw 2026.5.7 (eeef486)
Your personal assistant, minus the passive-aggressive calendar reminders.

Restarted Scheduled Task: OpenClaw Gateway
Gateway restart failed after 93s: service stayed stopped and port 18789 stayed free.
Service runtime: status=stopped, state=Queued
Gateway port 18789 status: free.
Gateway restart failed after 93s: service stayed stopped and health checks never came up.
Tip: openclaw gateway status --deep
Tip: openclaw doctor
PS C:\Users\jabuc>

primal windBOT May 11, 2026, 9:28 PM

#

Okay — now it’s specifically a Windows Scheduled Task startup problem, not Discord and not port conflict.

state=Queued + port 18789 free means Windows accepted the task run request, but the gateway process never actually started/listened.

Run these next:

openclaw gateway status --deep
openclaw doctor
openclaw logs --tail 200

Then try reinstalling the scheduled task:

openclaw gateway install --force

#

openclaw gateway restart
openclaw gateway status --deep

If it still stays Queued, test whether OpenClaw itself can start outside Task Scheduler:

openclaw gateway run

If gateway run works, leave it open temporarily — your Discord bot should work while that window is running. Then the remaining fix is just the Windows service/task wrapper.

If gateway run fails, paste the actual error from that command; that’ll be the root cause.

dreamy turtle May 11, 2026, 9:30 PM

#

Runtime: stopped (state Queued, last run 0, last run time 5/11/2026 4:22:26 PM, Task Last Run Result=0; treating as not running.)
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
connect ECONNREFUSED 127.0.0.1:18789
Capability: unknown

Service is loaded but not running (likely exited immediately).
File logs: C:\Users\jabuc\AppData\Local\Temp\openclaw\openclaw-2026-05-11.log
Logs: schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST
Restart attempts: C:\Users\jabuc.openclaw\logs\gateway-restart.log

Other gateway-like services detected (best effort):

\OpenClaw Gateway (system, task: \OpenClaw Gateway, run: C:\Users\jabuc.openclaw\gateway.cmd)
Cleanup hint: schtasks /Delete /TN "OpenClaw Gateway" /F

Recommendation: run a single gateway per machine for most setups. One gateway supports multiple agents (see docs: /gateway#multiple-gateways-same-host).
If you need multiple gateways (e.g., a rescue bot on the same host), isolate ports + config/state (see docs: /gateway#multiple-gateways-same-host).

primal windBOT May 11, 2026, 9:30 PM

#

Yep — this confirms the scheduled task is launching and then immediately exits (or never gets to the gateway listener). The next source of truth is the actual file log it printed:

Get-Content "C:\Users\jabuc\AppData\Local\Temp\openclaw\openclaw-2026-05-11.log" -Tail 200
schtasks /Query /TN "OpenClaw Gateway" /V /FO LIST

Also test the exact wrapper the task runs:

& "C:\Users\jabuc\.openclaw\gateway.cmd"

If that prints an error, paste it — that’s probably the real cause.

If gateway.cmd works in your terminal but the Scheduled Task stays queued/stopped, reinstall the task:

#

schtasks /Delete /TN "OpenClaw Gateway" /F
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status --deep

Only delete that task if this is your one intended OpenClaw gateway task. The status output is hinting at a duplicate/stale gateway service, but the log + gateway.cmd test will tell us whether it’s stale task metadata or a startup crash.

frank prism May 11, 2026, 9:31 PM

#

@primal wind
I’m running OpenClaw 2026.5.6 on Windows with Node v24.14.0. I’m trying to run multiple Discord bot accounts in one OpenClaw gateway process with native commands/native skill commands enabled.

What I verified:

All 5 Discord bot tokens work outside OpenClaw.
Direct Discord REST /users/@me succeeds for each token.
Direct Discord Gateway tests reach READY and receive heartbeat ACKs for each token.
OpenClaw with 1 Discord account works.
OpenClaw with Discord enabled, native commands enabled, and native skill commands enabled works for the default account.
Gateway RPC is healthy with one Discord account.
Cron delivery to Discord works again with one account.

What fails:

Enabling a second Discord account causes OpenClaw gateway instability.
With 2 accounts, both Discord gateway websockets open, but OpenClaw logs:
- discord: gateway READY wait timed out after 60000ms
- Gateway heartbeat ACK timeout
- local gateway status --json RPC timeout
The same behavior happens with all 5 accounts enabled.
This appears to be OpenClaw’s multi-Discord-account startup/runtime path, not token/network failure.

Relevant environment:

OpenClaw: 2026.5.6
OS: Windows
Node: v24.14.0
Gateway port: 18789
Discord config: one account stable; two or more accounts unstable
Native Discord commands: enabled
Native Discord skill commands: enabled

Mitigations already tried:

Disabled internal startup hooks.
Disabled startup model prewarm with OPENCLAW_SKIP_STARTUP_MODEL_PREWARM=1.
Removed duplicate skills.load.extraDirs.
Disabled skill watching.
Reduced duplicate native skill command discovery.
Tested isolated profiles.
Tested Node 22.14.0 separately; Node version alone did not fix it.

Question:
Is running multiple Discord bot accounts in one OpenClaw gateway process currently supported? If yes, is there a required config pattern for multi-account Discord, or is this a known bug in 2026.5.6?

primal windBOT May 11, 2026, 9:32 PM

#

Short answer: yes, multi-Discord-account config is intended/supported, but what you’re describing sounds like a real bug/regression in the multi-account Discord startup path, not bad tokens.

The supported shape is:

{
  bindings: [
    { agentId: "main", match: { channel: "discord", accountId: "default" } },
    { agentId: "coding", match: { channel: "discord", accountId: "coding" } },
  ],
  channels: {
    discord: {
      enabled: true,
      accounts: {
        default: {
          token: { source: "env", provider: "default", id: "DISCORD_TOKEN_MAIN" },

#

          applicationId: "..."
        },
        coding: {
          token: { source: "env", provider: "default", id: "DISCORD_TOKEN_CODING" },
          applicationId: "..."
        }
      }
    }
  }
}

Important details:

Put token + applicationId per account. Don’t rely on top-level channels.discord.applicationId unless every account is the same app.
Bind each account explicitly with match.accountId.
DISCORD_BOT_TOKEN only applies to the default account.

#

Duplicate tokens are detected/deduped, but you already ruled that out.

Given your logs:

discord: gateway READY wait timed out after 60000ms
Gateway heartbeat ACK timeout
local gateway status --json RPC timeout

…and the fact that one account is stable while two accounts wedge the local RPC/event loop, I’d treat this as a 2026.5.6 bug or startup starvation issue. Please file it here with exactly the summary you posted: https://github.com/openclaw/openclaw/issues

Practical mitigations while waiting:

Upgrade to latest first if you can:

#

npm install -g openclaw@latest
openclaw gateway restart

For diagnosis, disable native skill command registration across Discord, keep normal native commands on:

openclaw config set channels.discord.commands.native true
openclaw config set channels.discord.commands.nativeSkills false
openclaw gateway restart

Or per-account:

#

openclaw config set channels.discord.accounts.coding.commands.nativeSkills false

Set per-account applicationId and longer READY windows:

channels: {
  discord: {
    accounts: {
      coding: {
        applicationId: "222222222222222222",
        gatewayReadyTimeoutMs: 120000,
        gatewayRuntimeReadyTimeoutMs: 120000
      }
    }

#

}
}

If you need all 5 bots online today: run separate isolated OpenClaw profiles/gateways on different ports as a workaround.

Docs: https://docs.openclaw.ai/channels/discord and https://docs.openclaw.ai/concepts/multi-agent

dreamy turtle May 11, 2026, 9:54 PM

#

how can i clear up old cached session

primal windBOT May 11, 2026, 9:55 PM

#

Depends what you mean by “old cached session”:

For the current Discord thread/session, easiest reset is to send the bot:

/reset

That clears the current session state/model override without wiping all stored history.

To clean old stored sessions from disk, use the sessions cleanup command:

openclaw sessions cleanup --all-agents --dry-run
openclaw sessions cleanup --all-agents --enforce

#

If you only have the main agent:

openclaw sessions cleanup --dry-run
openclaw sessions cleanup --enforce

If there are broken/stale entries pointing at missing transcript files:

openclaw sessions cleanup --all-agents --fix-missing --dry-run
openclaw sessions cleanup --all-agents --fix-missing --enforce

To inspect what exists first:

#

openclaw sessions --all-agents
openclaw sessions --all-agents --json

Session files live under roughly:

%USERPROFILE%\.openclaw\agents\<agentId>\sessions\sessions.json

I’d avoid hand-deleting that unless the gateway is stopped and you’ve made a backup. The cleanup command is the safer path. Docs: https://docs.openclaw.ai/cli/sessions

dreamy turtle May 11, 2026, 9:59 PM

#

gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 9e660b18-4cd0-44d9-ab13-5ad0f35eadef)
Session store: C:\Users\jabuc.openclaw\agents\main\sessions\sessions.json
Applied maintenance. Current entries: 3
PS C:\Users\jabuc>

primal windBOT May 11, 2026, 9:59 PM

#

Cleanup worked — you’re down to 3 session entries. The new error is separate:

scope upgrade pending approval (requestId: 9e660b18-4cd0-44d9-ab13-5ad0f35eadef)

That means the CLI/device you’re using needs broader Gateway scopes before it can do that operation.

Run:

openclaw devices list
openclaw devices approve 9e660b18-4cd0-44d9-ab13-5ad0f35eadef

If the request ID changed, use the newest one from openclaw devices list instead. You can preview the latest pending request with:

#

openclaw devices approve --latest

Then rerun whatever command failed.

Docs: https://docs.openclaw.ai/cli/devices

primal windBOT May 11, 2026, 10:47 PM

#

That plan is sensible, with one caution: if gateway status --json is already timing out before enabling the extra accounts, don’t trust the test yet. First get to a clean baseline.

I’d do the matrix like this:

Stop/clear the wedged gateway, then confirm one account is healthy:

openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

Inspect config with OpenClaw rather than PowerShell JSON parsing if possible, because openclaw.json is JSON5-ish:

openclaw config get channels.discord --json
openclaw config get bindings --json

#

Test in order:

1 account + native commands on + nativeSkills off
2 accounts + native commands on + nativeSkills off
5 accounts + native commands on + nativeSkills off
only then try nativeSkills back on

If 2 accounts still wedge with nativeSkills=false, per-account applicationIds set, explicit bindings[].match.accountId, and gatewayReadyTimeoutMs/gatewayRuntimeReadyTimeoutMs=120000, that’s strong bug-report evidence.

Also: keep a copy of openclaw.json before patching. If this is on Windows and the scheduled task gets stuck in Queued, run openclaw gateway run in the foreground for the test so Task Scheduler isn’t another variable.

frank prism May 12, 2026, 12:59 AM

#

@primal wind I applied the mitigations you suggested, but the issue still reproduces.

Environment:

Windows
Node v24.14.0
OpenClaw 2026.5.6 originally
Also tested OpenClaw 2026.5.7
Config uses per-account token + per-account applicationId
Each Discord route has explicit match.accountId, including default
Duplicate tokens were already ruled out by direct Discord gateway tests

Changes tested:

channels.discord.commands.native = true
channels.discord.commands.nativeSkills = false
Per-account commands.nativeSkills = false
Per-account gatewayReadyTimeoutMs = 120000
Per-account gatewayRuntimeReadyTimeoutMs = 120000
Tested OpenClaw 2026.5.7, then rolled back to 2026.5.6

Results:

5 Discord accounts: gateway reaches partial readiness/RPC sometimes, then multiple Gateway heartbeat ACK timeout errors.
2 Discord accounts, default + one extra account: same Gateway heartbeat ACK timeout.
1 default account on 2026.5.7 also became unstable.
Disabling native skill registration did not fix multi-account startup.
Upgrade to 2026.5.7 did not fix it and appeared worse locally.
After repeated failed starts, even Discord-disabled gateway could become half-responsive: listener opens, logs show gateway ready, but openclaw gateway status --json times out.

Representative errors:

discord: gateway READY wait timed out after 60000ms
Gateway heartbeat ACK timeout
GatewayTransportError: gateway timeout after 30000ms
fetch timeout reached; timer delayed ... likely event-loop starvation
liveness warnings showing phase channels.discord.start-account

Current mitigation:

Discord is disabled in production config.

Can you confirm whether this is a known regression in the Discord multi-account startup path, and whether there is a flag/build to disable Discord REST command cleanup/registration during startup? The failure reproduces even with nativeSkills disabled and with only two Discord accounts.

primal windBOT May 12, 2026, 12:59 AM

#

Yes — with what you’ve tested, this now looks like a known/reported regression class, not a config mistake.

I found matching public issues:

Multi-account Discord startup hangs at gateway readiness: https://github.com/openclaw/openclaw/issues/53132
Ready-timeout / multi-account stagger issue: https://github.com/openclaw/openclaw/issues/72273
2026.5.3/5.4+ gateway event-loop starvation + Discord heartbeat ACK/RPC timeouts: https://github.com/openclaw/openclaw/issues/77995

Your symptoms line up especially with the third one: local RPC timeouts, event-loop starvation, Discord /users/@me/heartbeat timeouts, and status calls becoming half-responsive.

For your specific question: yes, there is a config switch to disable Discord native REST command registration/cleanup during startup:

openclaw config set channels.discord.commands.native false
openclaw gateway restart

#

Or per account:

openclaw config set channels.discord.accounts.default.commands.native false
openclaw config set channels.discord.accounts.<accountId>.commands.native false

Important distinction:

nativeSkills=false

only disables native skill command registration. It does not disable the built-in Discord slash-command registration/reconciliation/cleanup path. For that, use:

#

commands.native=false

Docs say commands.native=false skips Discord slash-command registration and cleanup during startup; previously registered commands may remain visible in Discord until removed from the app.

I don’t see a separate “disable cleanup but keep registration” flag. The available mitigation is disabling native commands entirely for Discord while testing transport stability.

Given the 2026.5.x instability you saw, my practical next test would be:

openclaw config set channels.discord.commands.native false
openclaw config set channels.discord.commands.nativeSkills false
openclaw gateway restart
openclaw gateway status --deep
openclaw channels status --probe

#

If that still wedges with 2 accounts, the command registration path is probably not the main blocker anymore; it’s likely the Discord multi-account gateway/runtime path or broader 2026.5.x event-loop starvation regression. In that case, please add your Windows + Node v24.14.0 reproduction to the GitHub issue list above, or file a fresh issue if none matches exactly: https://github.com/openclaw/openclaw/issues

For production today: keeping Discord disabled, running only one Discord account, or splitting bots across separate isolated gateways/profiles are the safest workarounds.

frank prism May 12, 2026, 1:24 AM

#

primal wind Yes — with what you’ve tested, this now looks like a known/reported regression c...

I tested the additional mitigation:

channels.discord.commands.native = false
channels.discord.commands.nativeSkills = false
per-account commands.native = false
per-account commands.nativeSkills = false

All 5 Discord accounts were enabled for the test.

Result:

openclaw gateway status --deep initially passed with RPC ok.
openclaw channels status --probe then timed out.
Logs still showed Gateway heartbeat ACK timeout.
So disabling native REST command registration/cleanup improves startup but does not resolve the multi-account Discord heartbeat/RPC instability.

I reverted to OpenClaw 2026.5.6, disabled Discord in config, disabled all Discord accounts, and stopped the gateway listener to avoid leaving a half-responsive process running.

primal windBOT May 12, 2026, 1:25 AM

#

Thanks — that’s a solid isolation result.

At this point I’d call it not caused by native command registration/cleanup. Since it still reproduces with:

commands.native=false
commands.nativeSkills=false
per-account native/nativeSkills disabled
explicit per-account applicationId
explicit match.accountId
longer READY/runtime timeouts

…the remaining failure is almost certainly in the Discord multi-account gateway/runtime path or the broader 2026.5.x event-loop starvation regression.

Your current mitigation — Discord disabled + all Discord accounts disabled + gateway stopped — is the right safe move. A half-responsive gateway is worse than a cleanly stopped one.

If you file/update GitHub, I’d include exactly this new finding because it rules out a big suspect:

#

Disabling Discord native command registration and cleanup with channels.discord.commands.native=false, channels.discord.commands.nativeSkills=false, and per-account overrides improved initial startup but did not prevent channels status --probe timeout or Gateway heartbeat ACK timeout with 5 accounts.

Best issue targets:

https://github.com/openclaw/openclaw/issues/77995 for 2026.5.x event-loop/RPC/Discord heartbeat starvation
https://github.com/openclaw/openclaw/issues/53132 for Discord multi-account readiness hangs

For production until fixed: one Discord account per gateway/profile, or keep Discord disabled on this gateway.

frank prism May 14, 2026, 11:44 PM

#

primal wind Thanks — that’s a solid isolation result. At this point I’d call it **not cause...

did it get fixed yet

#My openclaw bot isnt starting on discord even when I ask it to restart in the dashboard