Gateway reconnect because of discord | Friends of the Crustacean 🦞🤝 | Page 1

wheat sundial Apr 28, 2026, 9:43 AM

#

09:35:24+00:00 info gateway/channels/discord {"subsystem":"gateway/channels/discord"} discord gateway: Gateway reconnect scheduled in 3632ms (invalid-session, resume=false)
Gateway not reachable. Is it running and accessible?

when i use openclaw status and show
Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────┘

kind terraceBOT Apr 28, 2026, 9:43 AM

#

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

desert berryBOT Apr 28, 2026, 9:44 AM

#

That empty Channels table means OpenClaw isn’t seeing any enabled channel runtime yet — either the Gateway isn’t reachable, or Discord isn’t enabled/token-resolved in the config.

First, please run:

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

Then check Discord config:

openclaw config get channels.discord.enabled
openclaw config get channels.discord.token

#

If Discord isn’t enabled/tokened, set it like this — don’t paste the bot token here:

export DISCORD_BOT_TOKEN="your_token_here"
openclaw config set channels.discord.token --ref-provider default --ref-source env --ref-id DISCORD_BOT_TOKEN
openclaw config set channels.discord.enabled true --strict-json
openclaw gateway restart

If you run OpenClaw as a service, make sure the service can see DISCORD_BOT_TOKEN — easiest is usually putting it in ~/.openclaw/.env, then restarting the gateway.

After restart:

openclaw gateway status
openclaw channels status --probe

#

openclaw logs --follow

The invalid-session, resume=false Discord log can happen during reconnects; if it loops forever, it usually points to token/intents/config/runtime visibility. Discord setup docs: https://docs.openclaw.ai/channels/discord
Troubleshooting ladder: https://docs.openclaw.ai/gateway/troubleshooting

wheat sundial Apr 28, 2026, 9:47 AM

#

But it link . when i use openclaw status -deep
Health
┌──────────┬───────────┬──────────────────────────────────────────────────────────────────────────────┐
│ Item │ Status │ Detail │
├──────────┼───────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Gateway │ reachable │ 2073ms │
│ Discord │ OK │ configured │
└──────────┴───────────┴──────────────────────────────────────────────────────────────────────────────┘

desert berryBOT Apr 28, 2026, 9:49 AM

#

That --deep result is good news: the Gateway is reachable now, and the running Gateway sees Discord configured.

The weird part is the empty Channels table in plain openclaw status. That usually means the fast local CLI view and the running Gateway view don’t agree — often different config path / different OpenClaw install / service using a different binary.

Please run these and paste the output:

openclaw --version
which openclaw
openclaw gateway status --deep
openclaw channels status --probe
openclaw doctor

If channels status --probe says Discord is OK/connected, then the invalid-session, resume=false line may just be Discord reconnecting and not the main problem.

If the bot is still not replying in a server channel, next checks are:

#

openclaw pairing list discord
openclaw logs --follow

Then send a test message mentioning the bot and watch logs for things like mention required, allowlist, pairing, or permission/intents errors.

Docs for the exact runbook: https://docs.openclaw.ai/channels/troubleshooting and Discord setup: https://docs.openclaw.ai/channels/discord

wheat sundial Apr 28, 2026, 11:18 AM

#

node@Macau_Disk:/app$ openclaw logs --follow

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

Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/node/.openclaw/openclaw.json
Bind: lan
Hint: run openclaw doctor.

desert berryBOT Apr 28, 2026, 11:19 AM

#

This points to a Gateway reachability mismatch, not Discord yet.

Your CLI is trying:

ws://127.0.0.1:18789
Config: /home/node/.openclaw/openclaw.json

If you’re inside Docker/container, 127.0.0.1 means inside that container, not your host or another container. So if the Gateway is running elsewhere, this CLI won’t see it.

Run from the same shell:

openclaw gateway status --deep
openclaw doctor

#

If Gateway is not running there, test-start it:

openclaw gateway --verbose

If Gateway is running on host/another container, target that instead:

openclaw gateway status --url ws://host.docker.internal:18789
openclaw logs --url ws://host.docker.internal:18789 --follow

On Linux Docker, host.docker.internal may not exist — use the Docker Compose service name or the host LAN IP.

For file logs without Gateway RPC:

#

tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Once openclaw gateway status is reachable, then check Discord:

openclaw channels status --probe

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

wheat sundial Apr 28, 2026, 11:26 AM

#

11:17:34+00:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","surface_error"],"runId":"active-memory-moij5on2-2db13589","stage":"assistant","decision":"surface_error","failoverReason":"timeout","profileFailureReason":"timeout","provider":"google-vertex","model":"gemini-2.5-flash-lite","sourceProvider":"google-vertex","sourceModel":"gemini-2.5-flash-lite","fallbackConfigured":false,"timedOut":true,"aborted":true} embedded run failover decision
11:17:48+00:00 info typing TTL reached (2m); stopping typing indicator
11:17:48+00:00 warn gateway/ws {"subsystem":"gateway/ws"} handshake timeout conn=7543113a-60c8-43de-8a9b-dbb28afb8aba peer=127.0.0.1:57602->127.0.0.1:18789 remote=127.0.0.1

desert berryBOT Apr 28, 2026, 11:27 AM

#

That log changes the diagnosis: Discord is probably not the main failure now.

OpenClaw received the Discord message — it started typing — then the assistant run timed out:

provider: google-vertex
model: gemini-2.5-flash-lite
failoverReason: timeout
fallbackConfigured: false

So the bot goes silent because the selected model timed out and there’s no fallback model configured.

Run:

#

openclaw models status
openclaw models fallbacks list
openclaw channels status --probe

Then either switch to a model/provider you know works:

openclaw models set <provider/model>
openclaw gateway restart

or add at least one fallback:

#

openclaw models fallbacks add <provider/model>
openclaw gateway restart

I won’t suggest specific model names here because they change fast — #models is best for current recommendations — but use a provider you already have auth for.

The typing TTL reached (2m) line is just the Discord typing indicator giving up after the model timeout. The gateway/ws handshake timeout is a local WebSocket client not completing auth/handshake; worth watching, but the clear blocker in this snippet is the model timeout/no fallback.

Docs: https://docs.openclaw.ai/concepts/models and https://docs.openclaw.ai/help/faq-models

wheat sundial Apr 28, 2026, 11:36 AM

#

TUI also very slow:
node@Macau_Disk:/app$ openclaw tui

🦞 OpenClaw 2026.4.26 (unknown) — iMessage green bubble energy, but for everyone.

openclaw tui - ws://127.0.0.1:18789 - agent maid_01 (maid_01) - session main

history failed: Error: gateway request timeout for chat.history
connected | press ctrl+c again to exit
agent maid_01 (maid_01) | session main (openclaw-tui) | google-vertex/gemini-3.1-flash-lite-preview | tokens 13k/205k (7%)

desert berryBOT Apr 28, 2026, 11:37 AM

#

Yep — that TUI output confirms this has moved beyond Discord.

connected + history failed: gateway request timeout for chat.history means the TUI reached the Gateway, but the Gateway is too slow/busy to answer a simple history request. The earlier model timeout is one issue, but chat.history timing out points at Gateway/session-store/host slowness too.

Try this isolate:

openclaw tui --session tui-smoke-test

If the new session is fast → the main session/history for maid_01 is likely heavy or stuck.
If it’s also slow → the Gateway process/host is saturated or wedged.

Then run:

#

openclaw gateway status --deep
openclaw gateway stability
openclaw tasks list --status running
openclaw sessions --agent maid_01 --verbose
openclaw models status

If the TUI has an active run stuck, press Esc or type:

/abort

Then restart the Gateway once:

#

openclaw gateway restart

After it comes back, verify:

openclaw channels status --probe
openclaw status --deep

If chat.history still times out after a clean restart, please run:

openclaw gateway diagnostics export

#

and file it at https://github.com/openclaw/openclaw/issues. Don’t paste tokens/secrets, but the diagnostics export is designed to redact sensitive payloads.

wheat sundial Apr 28, 2026, 11:48 AM

#

Cannot convert undefined or null to object

desert berryBOT Apr 28, 2026, 11:49 AM

#

That exact line is a generic JS crash, so we need the surrounding stack trace to know which part is throwing.

Please run:

openclaw logs --limit 500 --plain | grep -B25 -A25 "Cannot convert undefined or null to object"
openclaw config validate
openclaw doctor

Also test whether it’s only the current session:

openclaw tui --session fresh-test

If fresh-test works but main times out/crashes, the maid_01/main session history/store is probably the bad part. Don’t delete anything yet — just use a fresh session and collect diagnostics.

#Gateway reconnect because of discord