Fix: Discord WebSocket Resume Loop in OpenClaw (Code 1005)

TL;DR: If your Discord bot processes messages but responses never arrive, you're probably stuck in a WebSocket resume loop. Restart the gateway with openclaw gateway restart. Read on for monitoring tips and what's happening under the hood.

The Symptoms

You'll know you're hitting this bug when:

1. The bot receives messages. You can see it processing in the logs — it's reading your messages, generating responses, everything looks normal
2. Responses never arrive. The bot thinks it's sending replies, but nothing shows up in Discord
3. Logs show a loop. You see this pattern repeating endlessly:

WebSocket connection closed with code 1005
Attempting resume with backoff: 1000ms
WebSocket connection closed with code 1005
Attempting resume with backoff: 2000ms
WebSocket connection closed with code 1005
Attempting resume with backoff: 4000ms

The backoff increases but the connection never actually recovers. Your bot is stuck in zombie mode — alive but unable to communicate.

What's Happening

Discord's gateway uses WebSocket connections for real-time communication. When a connection drops (which happens regularly — the internet is messy), the client is supposed to "resume" the session using a session ID and sequence number.

Code 1005 means the connection closed without a status code. Discord's gateway just… stopped talking. No error, no reason, just silence.

OpenClaw's Discord client sees the disconnection and tries to resume, which is the correct behavior. But in this specific scenario, the resume itself fails — Discord doesn't accept the session — and instead of falling back to a fresh connection, the client keeps trying to resume with increasing backoff delays.

The result: an infinite loop where the bot thinks it's reconnecting but never actually establishes a working session.

Why This Happens

Several things can trigger it:

• Discord gateway maintenance. Discord rotates gateway servers without notice. Your session ID becomes invalid on the new server
• Long disconnections. If the bot was offline for too long, the session expired on Discord's end
• Network blips. Temporary network issues that last just long enough to invalidate the session
• Resource pressure. If the host machine is under memory or CPU pressure, the WebSocket heartbeat can miss its deadline, causing Discord to drop the session

The Fix

Immediate: Restart the Gateway

openclaw gateway restart

This kills the stuck WebSocket connection and establishes a completely fresh session. Your bot should be back online within a few seconds.

If you're running OpenClaw as a systemd service:

sudo systemctl restart openclaw

Monitoring: Catch It Early

The worst part of this bug is that it's silent. Your bot looks "online" in Discord (for a while), and you don't notice until someone tells you the bot isn't responding.

Check the logs:

openclaw gateway logs | grep -i "resume\|1005\|websocket"

If you see repeated "Attempting resume" entries, you're in the loop.

Set up a watchdog:

A simple cron job that checks for the pattern and restarts automatically:

# Add to crontab (crontab -e)
*/5 * * * * grep -c "Attempting resume" /var/log/openclaw/gateway.log | xargs -I {} test {} -gt 10 && openclaw gateway restart

This checks every 5 minutes, and if there are more than 10 resume attempts in the log, it restarts the gateway. Crude but effective until a proper fix lands.

The Right Fix (Feature Request)

What OpenClaw should do — and what we've requested — is implement a resume attempt limit:

1. Try to resume the session (current behavior)
2. After N failed resume attempts (say, 5), abandon the session
3. Start a completely fresh connection with a new session ID
4. Log a warning so you know it happened

This is standard practice for Discord bot libraries like discord.js. The OpenClaw Discord client should detect that a resume is perpetually failing and fall back to a fresh IDENTIFY instead of endlessly retrying RESUME.

Until this is implemented, manual restarts (or the watchdog cron) are your best options.

Prevention

You can't fully prevent Discord from dropping your WebSocket connection — that's just how the internet works. But you can reduce the frequency:

Use a stable network. WiFi connections drop more than wired. If your OpenClaw server is on WiFi (like a Raspberry Pi), consider switching to Ethernet.

Ensure adequate resources. If your server is swapping memory or spiking CPU, WebSocket heartbeats can be delayed past Discord's timeout. Monitor with:

free -h   # Check memory
top -bn1  # Check CPU

Keep OpenClaw updated. Connection handling improvements land regularly. Run:

npm update -g openclaw

Don't run multiple bot instances with the same token. This causes session conflicts where both instances fight over the same gateway session. One will always lose.

If It's Not Code 1005

Other Discord WebSocket codes you might see:

For other Discord issues, check our Discord Application ID guide.

The Bottom Line

The resume loop is annoying but not dangerous — your data is fine, and a restart fixes it immediately. It's a client-side connection handling issue that should eventually get a proper fix (auto-fallback to fresh connection after N failures).

Until then: monitor your logs, set up a watchdog if you can't afford downtime, and don't panic when it happens.

Don't want to manage server infrastructure? lobsterfarm provides managed OpenClaw hosting with deployment, updates, and support.

Get started with lobsterfarm → · Fix other OpenClaw issues →