discord stopped working.. | Friends of the Crustacean 🦞🤝 | Page 1

digital sun Apr 20, 2026, 8:23 PM

#

discord stopped working..

flat flameBOT Apr 20, 2026, 8:23 PM

#

terse frostBOT Apr 20, 2026, 8:23 PM

#

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

flat flameBOT Apr 20, 2026, 8:23 PM

#

cosmic quiverBOT Apr 20, 2026, 8:25 PM

#

Let’s narrow it down.

First, please paste:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe

And tell me which of these matches:

bot is offline entirely
bot is online but ignores guild/server messages
DMs stopped working
only one server/channel stopped working

#

For Discord specifically, the usual culprits are:

Message Content Intent got disabled
guild/channel allowlist or groupPolicy is blocking messages
requireMention is still on
DM pairing/DM policy is blocking replies

Docs:

Paste the outputs and I’ll help you pinpoint it.

digital sun Apr 21, 2026, 5:37 PM

#

│ Channel │ Enabled │ State │ Detail │
│ Discord │ ON │ OK │ token config (sha256:58f17929 · len 72) · accounts 1/1 │

Discord accounts
│ Account │ Status │ Notes │
│ default │ OK │ token:config │

Agents
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
│ main │ ABSENT │ 4 │ 8h ago │ ~/.openclaw/agents/main/sessions/sessions.json │
│ openclaw-support (openclaw-support) │ ABSENT │ 1 │ 3d ago │ ~/.openclaw/agents/openclaw-support/sessions/sessions.json │

Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/user1/.openclaw/openclaw.json
Bind: loopback

✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 5201 user1: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: serve · unknown · user1-utm-ubuntu.tail030c17.ts.net
https: https://user1-utm-ubuntu.tail030c17.ts.net
✓ Skills: 10 eligible · 0 missing · /home/user1/.openclaw/w.
✓ Channel issues (none)

cosmic quiverBOT Apr 21, 2026, 5:37 PM

#

This output is actually a good sign: the gateway is up and the Discord token loaded fine.

Also, this part is not the problem:

Port 18789 is already in use.
- Gateway already running locally.

That just means your gateway is already running.

So this looks more like Discord-side visibility/gating, not “gateway dead”.

Please paste these next:

#

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then, while openclaw logs --follow is running, send your bot one fresh test message in Discord and paste the new log lines.

Most likely causes from here are:

Message Content Intent got turned off in the Discord Developer Portal
the bot is only allowed in DMs / pairing mode
guild/channel allowlist is blocking that server/channel
requireMention is enabled, so non-mention messages get ignored

If you want, also tell me which exact symptom you see now:

#

bot shows offline
bot shows online but ignores server messages
DMs work, server channels don’t
nothing works anywhere

Docs:

digital sun Apr 21, 2026, 5:39 PM

#

bot doesn't write in discord and not responding.. however, the openclaw dashboard chat is working

another thing is, how to openclaw dashboard from mac? my openclaw is on ubuntu on UTM on macbook ...

cosmic quiverBOT Apr 21, 2026, 5:41 PM

#

That helps, yeah, this means OpenClaw itself is fine and the problem is probably just the Discord channel config/policy.

Most likely things to check:

Discord Developer Portal → Bot
Make sure Message Content Intent is enabled.
If you changed it, restart the gateway afterward.
Guild policy / allowlist
There’s a sneaky default here: if you only set DISCORD_BOT_TOKEN and never added a real channels.discord block, Discord guilds fall back to groupPolicy: "allowlist", so the bot can look healthy but ignore server messages.

Safer private-server config looks like this:
```
{
  channels: {
```

#

       discord: {
         enabled: true,
         groupPolicy: "allowlist",
         guilds: {
           "YOUR_SERVER_ID": {
             requireMention: false,
           },
         },
       },
     },
   }

If you want mention-only behavior, set requireMention: true instead.

If DMs also stopped

#

Check pairing:

openclaw pairing list discord

I still want these to confirm exactly where it’s failing:

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then send one test Discord message and paste the fresh log lines.

For the dashboard from your Mac:

#

Best if you already use Tailscale: try opening the URL your status showed on the Mac:
<https://user1-utm-ubuntu.tail030c17.ts.net>
If that doesn’t work, use an SSH tunnel from the Mac to the Ubuntu VM:
```
ssh -N -L 18789:127.0.0.1:18789 user@<ubuntu-vm-ip>
```
then open:

<http://127.0.0.1:18789/>
You can also run this inside Ubuntu to print the dashboard URL:
```
openclaw dashboard
```

#

Docs:

If you paste your channels.discord config block and the probe/log output, I can usually spot the exact issue fast.

digital sun Apr 22, 2026, 9:36 PM

#

"channels": {
"discord": {
"enabled": true,
"token": "xxxxx",
"groupPolicy": "disabled",
"guilds": {
"xxxx944": {
"channels": {
"xxx442": {
"requireMention": false,
"enabled": true
},
"xxx590": {
"requireMention": false,
"enabled": true
}
}
}
}
}
},

#

hi

digital sun Apr 23, 2026, 8:50 PM

#

?

cosmic quiverBOT Apr 23, 2026, 8:51 PM

#

Sorry, the key point is:

If dashboard chat works but Discord is dead, the problem is almost certainly Discord config/policy, not the core gateway.

Please send these 3 things so I can pinpoint it:

openclaw --version
openclaw channels status --probe
openclaw logs --follow

Then while openclaw logs --follow is running, send one test message to the bot in Discord and paste the new log lines.

Also check these two things right now:

Discord Developer Portal → Bot → Message Content Intent = ON

#

Your config has a real channels.discord block, not just a token

Minimal private-server example:

{
  channels: {
    discord: {
      enabled: true,
      groupPolicy: "allowlist",
      guilds: {
        "YOUR_SERVER_ID": {
          requireMention: false,
        },
      },
    },

#

  },
}

For the dashboard from your Mac:

easiest: open the Tailscale URL from the Mac
or SSH tunnel:

ssh -N -L 18789:127.0.0.1:18789 user@<ubuntu-vm-ip>

then open:

http://127.0.0.1:18789/

#

Docs:

If you paste channels status --probe and the test log lines, I can usually tell you the exact blocker fast.

digital sun Apr 24, 2026, 1:57 AM

#

user1@user1:~/.openclaw$ openclaw --version
openclaw channels status --probe
openclaw logs --follow
OpenClaw 2026.4.15 (041266a)

🦞 OpenClaw 2026.4.15 (041266a) — I'm like tmux: confusing at first, then suddenly you can't live without me.

│
◇
Gateway reachable.

Discord default: enabled, configured, running, disconnected, in:6h ago, bot:@yug, token:config, intents:content=limited, works, audit ok, error:channel stop timed out after 5000ms

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

🦞 OpenClaw 2026.4.15 (041266a) — Alexa, but with taste.

Log file: /tmp/openclaw/openclaw-2026-04-21.log
12:47:25+00:00 info No pending discord pairing requests.
19:06:52+00:00 info Gateway reachable.

Discord default: enabled, configured, running, disconnected, in:6h ago, bot:@yug, token:*** intents:content=limited, works, audit ok, error:channel stop timed out after 5000ms

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

What's my tailscale url

cosmic quiverBOT Apr 24, 2026, 1:59 AM

#

From the status you pasted earlier, your Tailscale Serve URL looks like:

https://user1-utm-ubuntu.tail030c17.ts.net

On your Mac, try opening that directly.

A couple quick notes:

intents:content=limited is not necessarily the problem. For bots under 100 servers, that can still be fine.
The bigger red flag is this part: disconnected and error: channel stop timed out after 5000ms.

So I’d try this next on Ubuntu:

openclaw gateway restart
openclaw channels status --probe

#

openclaw logs --follow

Then send one Discord test message and paste the fresh log lines.

If the dashboard opens on Mac and asks for auth, use the Control UI fields at Control → Overview → Gateway Access and paste your Gateway Token or Password there.

If you want to re-print the dashboard link/URL from Ubuntu, run:

openclaw dashboard

Docs:

#

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

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

digital sun Apr 24, 2026, 3:25 AM

#

ser1@user1:~/.openclaw$ openclaw --version
openclaw channels status --probe
openclaw logs --follow
OpenClaw 2026.4.15 (041266a)

🦞 OpenClaw 2026.4.15 (041266a) — I'm like tmux: confusing at first, then suddenly you can't live without me.

│
◇
Gateway reachable.

Discord default: enabled, configured, running, disconnected, in:6h ago, bot:@yug, token:config, intents:content=limited, works, audit ok, error:channel stop timed out after 5000ms

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

🦞 OpenClaw 2026.4.15 (041266a) — Alexa, but with taste.

Log file: /tmp/openclaw/openclaw-2026-04-21.log
12:47:25+00:00 info No pending discord pairing requests.
19:06:52+00:00 info Gateway reachable.

Discord default: enabled, configured, running, disconnected, in:6h ago, bot:@yug, token:*** intents:content=limited, works, audit ok, error:channel stop timed out after 5000ms

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

cosmic quiverBOT Apr 24, 2026, 3:26 AM

#

Yep, this isolates it.

The important part is:

running, disconnected ... error: channel stop timed out after 5000ms

So:

Discord token/config basically looks valid (works, audit ok)
intents:content=limited is usually fine
the thing that’s broken is the live Discord transport, which is currently disconnected/stuck

That also explains why dashboard chat still works.

Do this next on Ubuntu:

#

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

Then send one fresh Discord test message and paste the new log lines after the restart.

Right now, the logs --follow output you pasted is mostly just repeating status, not the actual failure event.

Also double check in Discord Developer Portal:

Bot → Message Content Intent = ON

If you changed that, restart the gateway again.

For your Tailscale URL, from the earlier status it looks like:

#

https://user1-utm-ubuntu.tail030c17.ts.net

Try opening that on your Mac.

If it does not open reliably, the safest path is an SSH tunnel from the Mac:

ssh -N -L 18789:127.0.0.1:18789 user1@<ubuntu-vm-ip>

Then open:

http://127.0.0.1:18789/

If the dashboard asks for auth, use the Gateway Token or Password in Control → Overview → Gateway Access.

Docs:

#

Paste the output after openclaw gateway restart, that should give the real clue.

digital sun Apr 24, 2026, 3:29 AM

#

ser1@user1:~/.openclaw$ openclaw --version
openclaw channels status --probe
openclaw logs --follow
OpenClaw 2026.4.15 (041266a)

🦞 OpenClaw 2026.4.15 (041266a) — I'm like tmux: confusing at first, then suddenly you can't live without me.

│
◇
Gateway reachable.

Discord default: enabled, configured, running, disconnected, in:6h ago, bot:@yug, token:config, intents:content=limited, works, audit ok, error:channel stop timed out after 5000ms

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

🦞 OpenClaw 2026.4.15 (041266a) — Alexa, but with taste.

Log file: /tmp/openclaw/openclaw-2026-04-21.log
12:47:25+00:00 info No pending discord pairing requests.
19:06:52+00:00 info Gateway reachable.

Discord default: enabled, configured, running, disconnected, in:6h ago, bot:@yug, token:*** intents:content=limited, works, audit ok, error:channel stop timed out after 5000ms

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

cosmic quiverBOT Apr 24, 2026, 3:30 AM

#

You pasted the same old output again, so we still haven’t tested the fix yet 🙂

The key line is still:

running, disconnected ... error: channel stop timed out after 5000ms

So the likely issue is: Discord transport is wedged, not your token.

Please run these exactly:

openclaw gateway restart
openclaw channels status --probe
tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

#

Then:

send one fresh Discord test message to the bot

run this again:

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

paste both outputs here

A couple notes:

intents:content=limited is usually fine, not the main problem
the important part is disconnected + channel stop timed out

Your Tailscale URL from the earlier status looks like:

https://user1-utm-ubuntu.tail030c17.ts.net

#

If that does not open on your Mac, use an SSH tunnel instead:

ssh -N -L 18789:127.0.0.1:18789 user1@<ubuntu-vm-ip>

then open:

http://127.0.0.1:18789/

Docs:

Paste the restart output + fresh tail output and I’ll help you read it.

digital sun Apr 24, 2026, 3:32 AM

#

before sending msg:
{"0":"{"subsystem":"gateway/ws"}","1":"⇄ res ✓ channels.status 6768ms conn=53867ebf…c74b id=c1959dff…4c2d","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"gateway/ws"}","parentNames":["openclaw"],"date":"2026-04-21T20:39:53.631Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/user1/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:324:14","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:324","fileColumn":"14","fileLine":"324","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:324","method":"logToFile"}},"time":"2026-04-21T13:39:53.631-07:00"}
{"0":"\u001b[38;2;47;191;113mGateway reachable.\u001b[39m\n- Discord default: enabled, configured, running, disconnected, bot:@yug, token:config, intents:content=limited, works, audit ok\n\nTip: \u001b]8;;https://docs.openclaw.ai/cli#status\u0007status --deep\u001b]8;;\u0007 adds gateway health probes to status output (requires a reachable gateway).","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"openclaw","date":"2026-04-21T20:39:53.643Z","logLevelId":3,"logLevelName":"INFO","path":{"fullFilePath":"file:///home/user1/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:153:46","fileName":"subsystem-Cgmckbux.js","fileNameWithLine":"subsystem-Cgmckbux.js:153","fileColumn":"46","fileLine":"153","filePath":"/home/user1/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js","filePathWithLine":"/home/user1/.npm-global/lib/node_modules/openclaw/dist/subsystem-Cgmckbux.js:153","method":"console.log"}},"time":"2026-04-21T13:39:53.645-07:00"}
user1@user1:~/.openclaw$

cosmic quiverBOT Apr 24, 2026, 3:33 AM

#

Nice, this confirms one thing: that was only the “before” state, and it’s still just status output, not the Discord failure itself.

Also, this is suspicious:

you’re on 2026-04-24
but the log file shown is still /tmp/openclaw/openclaw-2026-04-21.log

So let’s force a clean restart and grab the newest log directly.

Run these exactly:

openclaw gateway restart
sleep 5
openclaw channels status --probe
ls -lt /tmp/openclaw/openclaw-*.log | head

#

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

Then send one test message to the bot in Discord, and immediately run:

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

Paste the output from:

after restart
after the test message

Right now the core symptom is still:

#

Discord ... running, disconnected

So the bot is not actually attached to Discord’s live gateway, which is why it cannot read or write there, even though dashboard chat works.

For your Mac dashboard, your Tailscale URL should be:

https://user1-utm-ubuntu.tail030c17.ts.net

If that’s flaky, use SSH tunneling:

ssh -N -L 18789:127.0.0.1:18789 user1@<ubuntu-vm-ip>

Then open:

#

http://127.0.0.1:18789/

Docs:

Paste those two fresh tails and I’ll help decode them.

digital sun Apr 24, 2026, 3:35 AM

#

user1@user1:~/.openclaw$ openclaw gateway restart
sleep 5
openclaw channels status --probe
ls -lt /tmp/openclaw/openclaw-*.log | head

🦞 OpenClaw 2026.4.15 (041266a) — WhatsApp automation without the "please accept our new privacy policy".

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.15 (041266a) — I'm the reason your shell history looks like a hacker-movie montage.

│
◇
Gateway reachable.

Discord default: enabled, configured, running, disconnected, bot:@yug, token:config, intents:content=limited, works, audit ok, error:Gateway reconnect scheduled in 2120ms (close, resume=false)

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
-rw-rw-r-- 1 user1 user1 133954 Apr 21 13:42 /tmp/openclaw/openclaw-2026-04-21.log
-rw-rw-r-- 1 user1 user1 411934 Apr 21 13:39 /tmp/openclaw/openclaw-2026-04-20.log
user1@user1:~/.openclaw$

cosmic quiverBOT Apr 24, 2026, 3:36 AM

#

This is finally the useful clue.

works, audit ok means the Discord token/REST API is fine.

But this:

disconnected
error: Gateway reconnect scheduled in 2120ms (close, resume=false)

means the live Discord gateway websocket is dropping/restarting in a loop. So this is not an allowlist / requireMention problem anymore.

Because you’re running the gateway as a systemd service, the next step is to read the service journal, not the old /tmp file.

Please run:

#

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

If you have rg, even better:

journalctl --user -u openclaw-gateway.service -n 200 --no-pager | rg -i 'discord|gateway websocket|close code|4014|reconnect|ready|fatal|intent'

I’m looking for one of these exact signatures:

close code 4014 / disallowed intents
Gateway websocket closed: ...
discord gateway did not reach READY ...
Fatal gateway close code ...

#

Quick interpretation:

4014 / disallowed intents → enable Message Content Intent (and ideally Server Members Intent) in Discord Developer Portal, then openclaw gateway restart
did not reach READY → websocket startup is failing, usually network/session/runtime side
fatal close code → the code will tell us exactly what Discord is rejecting

So yeah, good news and bad news:

good: your bot token is probably okay
bad: the Discord realtime connection is what’s broken

Paste the journalctl output and I’ll decode it.

digital sun Apr 24, 2026, 3:40 AM

#

https://pastebin.com/gazF0j4e

cosmic quiverBOT Apr 24, 2026, 3:42 AM

#

Ah, Pastebin made that a Burn After Read paste, so it’s gone from my side now.

But we’re close. What we know already:

token/REST is fine (works, audit ok)
the problem is the Discord realtime websocket reconnecting in a loop

Please rerun this and paste the output directly here, or use a non-expiring paste:

journalctl --user -u openclaw-gateway.service -n 300 --no-pager | grep -Ei 'discord|gateway websocket|close code|4014|ready|reconnect|fatal|identify|resume'

If grep -E gives trouble, use:

#

journalctl --user -u openclaw-gateway.service -n 300 --no-pager

and paste the chunk around lines mentioning:

Gateway websocket closed
close code
READY
fatal
reconnect

Based on everything so far, I’m specifically trying to catch one of these:

4014 / disallowed intents
did not reach READY
fatal close code ...

#

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

digital sun Apr 24, 2026, 3:44 AM

#

https://pastebin.com/raw/uFs7dFQM

cosmic quiverBOT Apr 24, 2026, 3:45 AM

#

Found it.

The real error is:

gateway error: Error: certificate is not yet valid

So this is not a Discord token/intent problem. It’s a TLS clock problem on the Ubuntu VM.
OpenClaw can talk to Discord’s REST API, but the Discord websocket TLS handshake fails because the VM time is wrong.

This is common with UTM/suspended VMs.

Run this on Ubuntu:

#

date -u
timedatectl status
sudo timedatectl set-ntp true
sudo systemctl restart systemd-timesyncd
sudo reboot

After reboot:

date -u
openclaw gateway restart
openclaw channels status --probe

What you want to see is Discord becoming connected, not disconnected.

#

If the clock is still off after reboot:

fully shut down the UTM VM, then start it again, don’t just resume/suspend
make sure the VM has internet access for NTP
if needed, check:
```
timedatectl timesync-status
```

Only if the time is correct and it still fails, then try refreshing CA certs:

sudo apt update
sudo apt install --reinstall ca-certificates

But honestly, with certificate is not yet valid, I’d bet on wrong VM time.

#

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

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

digital sun Apr 24, 2026, 6:27 AM

#

user1@user1:~$ date -u
openclaw gateway restart
openclaw channels status --probe
Fri Apr 24 06:19:59 UTC 2026

🦞 OpenClaw 2026.4.15 (041266a) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.15 (041266a) — I don't judge, but your missing API keys are absolutely judging you.

│
◇
Gateway reachable.

Discord default: enabled, configured, running, disconnected, bot:@yug, token:config, intents:content=limited, works, audit ok

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).
user1@user1:~$ timedatectl timesync-status
Failed to query server: The name org.freedesktop.timesync1 was not provided by any .service files
user1@user1:~$ ^C
user1@user1:~$ ^C

cosmic quiverBOT Apr 24, 2026, 6:28 AM

#

Good, the VM clock now looks correct.

And this part:

timedatectl timesync-status
Failed to query server...

is not fatal by itself. It just means systemd-timesyncd is not the active time-sync service on that Ubuntu image.

So the old certificate is not yet valid issue may already be fixed.
Now we need the fresh Discord error after the latest restart, not the old one.

Please run:

#

journalctl --user -u openclaw-gateway.service --since "10 min ago" --no-pager | rg -i 'discord|gateway websocket|close code|reconnect|ready|fatal|certificate'

If rg is missing:

journalctl --user -u openclaw-gateway.service --since "10 min ago" --no-pager

Also do one more probe after a short wait:

sleep 15
openclaw channels status --probe

#

What I’m checking now is:

did the certificate error disappear
and if yes, what new reason is keeping Discord disconnected

So, progress: we likely fixed the first blocker. Now we need the new journal lines.

digital sun Apr 24, 2026, 6:29 AM

#

Apr 23 23:20:13 user1 node[3972]: 2026-04-23T23:20:13.694-07:00 [gateway] ready (6 plugins: acpx, browser, device-pair, discord, phone-control, talk-voice; 9.8s)
Apr 23 23:20:23 user1 node[3972]: 2026-04-23T23:20:23.502-07:00 [plugins] embedded acpx runtime backend ready
Apr 23 23:20:23 user1 node[3972]: 2026-04-23T23:20:23.684-07:00 [discord] [default] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
Apr 23 23:20:23 user1 node[3972]: 2026-04-23T23:20:23.684-07:00 [discord] [default] starting provider (@yug)
Apr 23 23:20:24 user1 node[3972]: 2026-04-23T23:20:24.482-07:00 [discord] channels resolved: 1494840596811218944/1494840597742223442 (guild:hubpa's server; channel:main-🦉), 1494840596811218944/1494882497903853590 (guild:hubpa's server; channel:openclaw-support-🦐)
Apr 23 23:20:25 user1 node[3972]: 2026-04-23T23:20:25.491-07:00 [discord] client initialized as 1494837882781958375 (yug); awaiting gateway readiness

cosmic quiverBOT Apr 24, 2026, 6:30 AM

#

Good news, the certificate error is gone. That was the first real blocker.

These new logs show Discord starts cleanly up to:

client initialized ... awaiting gateway readiness

So now I’d do the next two checks:

sleep 20
openclaw channels status --probe
journalctl --user -u openclaw-gateway.service -n 120 --no-pager

What I’m looking for now is whether it finally flips to connected, or whether there’s a new error after awaiting gateway readiness.

#

If it still says disconnected and there’s still no useful new error, my next recommendation is a full cold reboot of the UTM Ubuntu VM (power off, then start again, not suspend/resume), then:

openclaw gateway restart
openclaw channels status --probe

Why: the TLS/time issue looks fixed, but UTM suspend/resume can still leave networking or websocket state weird.

So, short version:

old problem: certificate is not yet valid ✅ likely fixed
next question: does Discord become connected after waiting a bit?
if not, do a cold VM reboot

Paste those two outputs and I’ll read the next clue. Docs: https://docs.openclaw.ai/gateway/troubleshooting

digital sun Apr 24, 2026, 6:33 AM

#

https://pastebin.com/raw/vJSdEzdc

cosmic quiverBOT Apr 24, 2026, 6:35 AM

#

Nice, this looks fixed 🎉

The key line is:

Gateway reachable.
- Discord default: enabled, configured, running, connected, in:just now, bot:@yug, token:config, intents:content=limited, works, audit ok

So the root cause really was the earlier TLS/clock issue:

certificate is not yet valid

After the VM time got corrected, Discord connected again.

#

One extra thing I noticed in the logs:

tailscale serve ... Access denied: serve config denied
Use 'sudo tailscale serve --bg --yes 18789'
To not require root, use 'sudo tailscale set --operator=$USER' once.

So if you want the dashboard from your Mac via Tailscale, fix that with:

sudo tailscale set --operator=$USER
sudo tailscale serve --bg --yes 18789

Then your Tailscale dashboard URL should work again.

#

Useful docs:

If Discord still seems quiet, send one fresh test message now that it’s connected.

Glad we caught that. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

digital sun Apr 24, 2026, 6:44 AM

#

none of them is working (discord, tailscale)

https://user1-utm-ubuntu.tail030c17.ts.net/chat?session=main is working on the same machine: ubuntu but not on mac... i'm already connected to tailscale on mac

cosmic quiverBOT Apr 24, 2026, 6:46 AM

#

You’re down to two separate issues now.

1) Discord

Your last probe showed Discord is connected again:

running, connected ... works, audit ok

But your logs also show OpenClaw only resolved two allowed channels in your server:

main-🦉
openclaw-support-🦐

So if you’re testing in any other channel or thread, it will stay silent.

Please test in one of those two channels. If you want, paste:

#

openclaw config get channels.discord

and I’ll check the allowlist.

2) Tailscale from Mac

This is still broken because the gateway service cannot manage Tailscale Serve:

Access denied: serve config denied
Use 'sudo tailscale serve --bg --yes 18789'
To not require root, use 'sudo tailscale set --operator=$USER' once.

Run this on Ubuntu:

#

sudo tailscale set --operator=$USER
openclaw gateway restart
tailscale serve status

If Serve still isn’t active, run:

sudo tailscale serve --bg --yes 18789

Then retry from the Mac.

Reliable fallback

If Tailscale keeps being annoying, use an SSH tunnel from the Mac:

#

ssh -N -L 18789:127.0.0.1:18789 user1@<ubuntu-vm-ip>

Then open:

http://127.0.0.1:18789/

Docs:

If you paste openclaw config get channels.discord, I can tell you exactly why Discord is ignoring the channel.

digital sun Apr 24, 2026, 6:47 AM

#

tested on main- channel

user1@user1:~$ openclaw config get channels.discord

🦞 OpenClaw 2026.4.15 (041266a) — I keep secrets like a vault... unless you print them in debug logs again.

{
"enabled": true,
"token": "OPENCLAW_REDACTED",
"groupPolicy": "disabled",
"guilds": {
"1494840596811218944": {
"channels": {
"1494840597742223442": {
"requireMention": false,
"enabled": true
},
"1494882497903853590": {
"requireMention": false,
"enabled": true
}
}
}
}
}
user1@user1:~$

cosmic quiverBOT Apr 24, 2026, 6:49 AM

#

Aha, found the Discord blocker.

Your config has:

"groupPolicy": "disabled"

That means guild/server messages are turned off, even though those channel entries exist.

So for Discord, change it to:

{
  channels: {
    discord: {

#

      enabled: true,
      groupPolicy: "allowlist",
      guilds: {
        "1494840596811218944": {
          channels: {
            "1494840597742223442": {
              requireMention: false,
              enabled: true
            },
            "1494882497903853590": {
              requireMention: false,
              enabled: true
            }
          }
        }

#

      }
    }
  }
}

Then restart:

openclaw gateway restart
openclaw channels status --probe

You want to see Discord still connected, then test again in main-🦉.

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

#

For Tailscale, the earlier logs showed this separate issue:

Access denied: serve config denied

So fix that on Ubuntu:

sudo tailscale set --operator=$USER
sudo tailscale serve --bg --yes 18789
tailscale serve status

Then try the URL again from the Mac.

So yeah, two separate problems:

#

Discord silent → groupPolicy: "disabled"
Mac can't reach Tailscale URL → Tailscale Serve permission issue

If you want, paste the output after changing groupPolicy and I’ll sanity check it.

digital sun Apr 24, 2026, 6:49 AM

#

user1@user1:~$
user1@user1:~$ sudo tailscale set --operator=$USER
openclaw gateway restart
tailscale serve status

🦞 OpenClaw 2026.4.15 (041266a) — Your config is valid, your assumptions are not.

Restarted systemd service: openclaw-gateway.service
https://user1-utm-ubuntu.tail030c17.ts.net (tailnet only)
|-- / proxy http://127.0.0.1:18789

user1@user1:~$
user1@user1:~$
user1@user1:~$
user1@user1:~$
user1@user1:~$ sudo tailscale serve --bg --yes 18789
Available within your tailnet:

https://user1-utm-ubuntu.tail030c17.ts.net/
|-- proxy http://127.0.0.1:18789

Serve started and running in the background.
To disable the proxy, run: tailscale serve --https=443 off

#

discord working after the config change

user1@user1:~/.openclaw$ sudo tailscale set --operator=$USER
sudo tailscale serve --bg --yes 18789
tailscale serve status
Available within your tailnet:

https://user1-utm-ubuntu.tail030c17.ts.net/
|-- proxy http://127.0.0.1:18789

Serve started and running in the background.
To disable the proxy, run: tailscale serve --https=443 off
https://user1-utm-ubuntu.tail030c17.ts.net (tailnet only)
|-- / proxy http://127.0.0.1:18789

user1@user1:~/.openclaw$

cosmic quiverBOT Apr 24, 2026, 6:58 AM

#

Nice, we got it. 🎉

Root causes were:

Discord: channels.discord.groupPolicy: "disabled" blocked guild messages
Tailscale: Serve permissions were missing, now fixed

So now from your Mac, try the root URL first:

https://user1-utm-ubuntu.tail030c17.ts.net/

If the dashboard opens but won’t connect, go to Control → Overview → Gateway Access and paste your Gateway Token or Password there.

If it still does not open on the Mac, run this on the Mac and paste the output:

#

tailscale status
tailscale ping user1-utm-ubuntu.tail030c17.ts.net

Docs:

Glad we caught both. If this fixed the Discord issue, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

digital sun Apr 24, 2026, 7:00 AM

#

tailscale not working yet

i logged in to tailscal website and it says

Last seen: Connected

cosmic quiverBOT Apr 24, 2026, 7:01 AM

#

Nice, Ubuntu side looks correct now. tailscale serve is up.

So the remaining problem is probably Mac-side Tailscale connectivity or DNS, not OpenClaw.

On the Mac, please run and paste:

tailscale status
tailscale ping user1-utm-ubuntu.tail030c17.ts.net

Also tell me what “not working” means exactly on the Mac:

page does not open at all
DNS / host not found
timeout
page opens, but dashboard won’t connect

#

One important detail: “Last seen: Connected” on the Tailscale website only tells you the Ubuntu VM is online. It does not prove your Mac is currently reaching it.

Quick sanity check on the Mac too:

make sure the Tailscale app itself says Connected
then try the root URL again, not /chat first:

https://user1-utm-ubuntu.tail030c17.ts.net/

If tailscale ping works but the browser still fails, then it’s probably a browser/auth issue. If tailscale ping fails, it’s a tailnet/connectivity issue.

digital sun Apr 24, 2026, 7:03 AM

#

➜ ~ tailscale status
tailscale ping user1-utm-ubuntu.tail030c17.ts.net
Tailscale is stopped.
Tailscale is stopped.
➜ ~

but on the menu bar, it says tailscale connected.. also in vpn -> it says it is connected

cosmic quiverBOT Apr 24, 2026, 7:04 AM

#

Yep, that explains it.

If the menu bar says connected but Terminal says:

Tailscale is stopped.

then your Mac is probably using the wrong tailscale CLI binary (usually a duplicate install), or the app/CLI got out of sync.

Run these on the Mac:

which tailscale
ls -l "$(which tailscale)"
/Applications/Tailscale.app/Contents/MacOS/Tailscale status

#

/Applications/Tailscale.app/Contents/MacOS/Tailscale ping user1-utm-ubuntu.tail030c17.ts.net

Then paste the output.

What I expect:

if the app-bundled CLI works, your current tailscale in PATH is the wrong one
if the app-bundled CLI also says stopped, the Mac Tailscale app itself is wedged

If it’s wedged, easiest fix is:

Quit Tailscale completely from the menu bar
Re-open Tailscale
Turn it off/on once
Retry the app-bundled commands above

#

Also, for immediate access, don’t wait on Tailscale, use an SSH tunnel from the Mac:

ssh -N -L 18789:127.0.0.1:18789 user1@<ubuntu-vm-ip>

Then open:

http://127.0.0.1:18789/

So, Discord is fixed. Now we’re just debugging the Mac’s Tailscale client.

digital sun Apr 24, 2026, 7:06 AM

#

https://pastebin.com/raw/E79jcbK1

cosmic quiverBOT Apr 24, 2026, 7:07 AM

#

Nice, this narrows it down a lot.

Your Mac Tailscale is now connected. This proves it:

100.64.64.127  user1-utm-ubuntu  hubpages.my@  linux

So the remaining problem is not OpenClaw and not general Tailscale connectivity, it’s MagicDNS resolution on the Mac:

lookup user1-utm-ubuntu.tail030c17.ts.net: no such host

What that means

Network path works
MagicDNS name does not resolve on the Mac

#

Quick test on the Mac

Run:

tailscale ping 100.64.64.127
nslookup user1-utm-ubuntu.tail030c17.ts.net 100.100.100.100

Most likely fix

In the Tailscale admin console, check:

DNS
MagicDNS = enabled

If MagicDNS is already enabled, then it’s probably just the Mac not using Tailscale DNS correctly. Easiest fixes:

turn Tailscale off/on on the Mac

#

fully quit and reopen the Tailscale app

retry:

/Applications/Tailscale.app/Contents/MacOS/Tailscale status
nslookup user1-utm-ubuntu.tail030c17.ts.net 100.100.100.100

Immediate fallback

Since Discord is fixed, if you need dashboard access right now, use SSH tunnel from the Mac:

ssh -N -L 18789:127.0.0.1:18789 user1@<ubuntu-vm-ip>

Then open:

http://127.0.0.1:18789/

#

If you paste the two command outputs above, I can tell you whether it’s:

MagicDNS disabled, or
Mac DNS stuck/out of sync.

digital sun Apr 24, 2026, 7:12 AM

#

➜ ~ tailscale ping 100.64.64.127
nslookup user1-utm-ubuntu.tail030c17.ts.net 100.100.100.100
pong from user1-utm-ubuntu (100.64.64.127) via DERP(sea) in 53ms
pong from user1-utm-ubuntu (100.64.64.127) via DERP(sea) in 52ms
pong from user1-utm-ubuntu (100.64.64.127) via DERP(sea) in 42ms
pong from user1-utm-ubuntu (100.64.64.127) via DERP(sea) in 47ms
^C
➜ ~

cosmic quiverBOT Apr 24, 2026, 7:12 AM

#

That ping is actually a good sign.

tailscale ping 100.64.64.127

working means your Mac can reach the Ubuntu VM over Tailscale.

Also, your second command never ran, because tailscale ping kept running until you hit Ctrl-C.

Please run these separately on the Mac:

nslookup user1-utm-ubuntu.tail030c17.ts.net 100.100.100.100
curl -I https://user1-utm-ubuntu.tail030c17.ts.net/

#

What this tells us:

if nslookup fails, it’s a MagicDNS/DNS problem
if nslookup works but curl fails, it’s an HTTPS/Serve/browser problem

One more helpful check:

open https://100.64.64.127:18789

That probably won’t be the final nice path, but it helps tell whether plain tailnet reachability works outside MagicDNS.

Small note: via DERP(sea) means the connection is being relayed, not direct. That’s okay for testing.

Paste the nslookup and curl -I outputs and I’ll tell you the exact next fix.

digital sun Apr 24, 2026, 7:13 AM

#

Secure Connection Failed

An error occurred during a connection to 100.64.64.127. Peer reports it experienced an internal error.

Error code: SSL_ERROR_INTERNAL_ERROR_ALERT

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

Learn more…

➜ ~ nslookup user1-utm-ubuntu.tail030c17.ts.net 100.100.100.100
curl -I https://user1-utm-ubuntu.tail030c17.ts.net/
Server: 100.100.100.100
Address: 100.100.100.100#53

Name: user1-utm-ubuntu.tail030c17.ts.net
Address: 100.64.64.127

curl: (6) Could not resolve host: user1-utm-ubuntu.tail030c17.ts.net
➜ ~

cosmic quiverBOT Apr 24, 2026, 7:14 AM

#

Perfect, this narrows it down.

nslookup ... 100.100.100.100 works → MagicDNS exists
plain curl https://user1-utm-ubuntu.tail030c17.ts.net/ fails to resolve → your Mac system DNS is not using Tailscale DNS
https://100.64.64.127 giving SSL error is expected. The cert is for user1-utm-ubuntu.tail030c17.ts.net, not the raw IP.

So OpenClaw/Tailscale Serve on Ubuntu is fine now. The remaining issue is Mac DNS integration.

Please run these on the Mac:

/Applications/Tailscale.app/Contents/MacOS/Tailscale set --accept-dns=true
scutil --dns | rg -i 'tailscale|100\\.100\\.100\\.100'
curl -I --resolve user1-utm-ubuntu.tail030c17.ts.net:443:100.64.64.127 https://user1-utm-ubuntu.tail030c17.ts.net/

What I expect:

#

if the curl --resolve ... command works, the site is fine and the issue is definitely just Mac DNS
if scutil --dns does not show Tailscale / 100.100.100.100, then the Mac app is connected but not owning DNS

If DNS still won’t stick, do this on the Mac:

Quit Tailscale completely
Re-open it
Toggle it off/on once

Retry:

/Applications/Tailscale.app/Contents/MacOS/Tailscale set --accept-dns=true
scutil --dns | rg -i 'tailscale|100\\.100\\.100\\.100'

If you want immediate access while that’s flaky, SSH tunnel is still the clean fallback:

#

ssh -N -L 18789:127.0.0.1:18789 user1@100.64.64.127

Then open:

http://127.0.0.1:18789/

Paste the two outputs and I’ll tell you the exact next fix.

digital sun Apr 24, 2026, 7:19 AM

#

➜ ~ /Applications/Tailscale.app/Contents/MacOS/Tailscale set --accept-dns=true
scutil --dns | rg -i 'tailscale|100\.100\.100\.100'
curl -I --resolve user1-utm-ubuntu.tail030c17.ts.net:443:100.64.64.127 https://user1-utm-ubuntu.tail030c17.ts.net/
zsh: command not found: rg
HTTP/2 200
cache-control: no-cache
content-security-policy: default-src 'self'; base-uri 'none'; object-src 'none'; frame-ancestors 'none'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' ws: wss:
content-type: text/html; charset=utf-8
date: Fri, 24 Apr 2026 07:19:22 GMT
permissions-policy: camera=(), microphone=(), geolocation=()
referrer-policy: no-referrer
x-content-type-options: nosniff
x-frame-options: DENY

➜ ~

cosmic quiverBOT Apr 24, 2026, 7:20 AM

#

Nice, this proves the important part:

curl --resolve ... https://user1-utm-ubuntu.tail030c17.ts.net/
HTTP/2 200

So:

OpenClaw is fine
Tailscale Serve on Ubuntu is fine
the only thing still broken is Mac DNS using MagicDNS

Also, rg just isn’t installed on your Mac, no big deal.

Run this instead:

#

scutil --dns | grep -Ei 'tailscale|100\.100\.100\.100'

If you don’t see 100.100.100.100, then the Mac is still not using Tailscale DNS even though Tailscale is connected.

At that point, I’d do this on the Mac:

Quit Tailscale completely
Re-open it
Toggle it off/on

Run again:

/Applications/Tailscale.app/Contents/MacOS/Tailscale set --accept-dns=true
scutil --dns | grep -Ei 'tailscale|100\.100\.100\.100'

#

If that still doesn’t show up, I’d suspect another DNS/VPN app on the Mac is overriding DNS.

Immediate fallback

Since the server itself is reachable, you can use this right now from the Mac:

ssh -N -L 18789:127.0.0.1:18789 user1@100.64.64.127

Then open:

http://127.0.0.1:18789/

So yeah, good news: this is no longer an OpenClaw problem, it’s just Mac Tailscale DNS integration now.

digital sun Apr 24, 2026, 7:23 AM

#

➜ ~ scutil --dns | grep -Ei 'tailscale|100.100.100.100'
nameserver[0] : 100.100.100.100
nameserver[0] : 100.100.100.100
nameserver[0] : 100.100.100.100
➜ ~
➜ ~

cosmic quiverBOT Apr 24, 2026, 7:24 AM

#

Nice, that means your Mac is using Tailscale DNS now.

nameserver[0] : 100.100.100.100

So at this point, retry these on the Mac:

curl -I https://user1-utm-ubuntu.tail030c17.ts.net/
open https://user1-utm-ubuntu.tail030c17.ts.net/

If it still says could not resolve host, it’s probably just a stale DNS cache on macOS. Flush it:

#

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Then try the URL again.

If the browser still acts weird after that, use a private window or restart the browser, because negative DNS results can get cached there too.

So the status now is:

Discord: fixed
OpenClaw + Tailscale Serve: fixed
Mac DNS: looks fixed now too, may just need cache flush

If the root URL opens but the dashboard won’t connect, paste that exact error and I’ll help with the last step.

digital sun Apr 24, 2026, 7:25 AM

#

url working.. https://user1-utm-ubuntu.tail030c17.ts.net/chat?session=main

token not working...pairing required

cosmic quiverBOT Apr 24, 2026, 7:28 AM

#

That part is expected.

On the Control UI, the token/password does not bypass browser device pairing.
Over Tailscale, a new browser/device still needs a one-time pairing approval.

Run this on Ubuntu:

openclaw devices list
openclaw devices approve <requestId>

Then reload:

https://user1-utm-ubuntu.tail030c17.ts.net/chat?session=main

A couple notes:

#

if you changed browser/profile or cleared site data, it may create a new pairing request
if approve fails, run openclaw devices list again and use the newest requestId

So the state now is:

Discord: fixed
Tailscale URL: fixed
Remaining step: approve the Mac browser device

Docs:

If you paste openclaw devices list, I can tell you which request to approve.

digital sun Apr 24, 2026, 7:33 AM

#

no unapproved device

cosmic quiverBOT Apr 24, 2026, 7:34 AM

#

Got it. If there’s no pending request, then this is usually not first-time pairing, it’s a stale paired browser/device record.

Try this on Ubuntu:

openclaw doctor
openclaw devices list

Look for the already paired browser/operator device for your Mac browser.

Then do this recovery flow:

openclaw devices rotate --device <deviceId> --role operator

#

Reload the Mac page.

If it still says pairing required, do the harder reset:

openclaw devices remove <deviceId>

Then refresh the page on the Mac once. That should create a new pending request. Then:

openclaw devices list
openclaw devices approve <requestId>

Docs-backed reason: this is the common “already paired but still getting pairing required” case, usually stale token/device-identity drift.

#

Also, don’t worry about the URL anymore, that part is working now.

If you paste openclaw devices list, I can help spot which deviceId to rotate/remove.

flat flameBOT Apr 24, 2026, 7:52 AM

#

digital sun Apr 24, 2026, 9:35 PM

#

https://pastebin.com/4LqFi9nJ

#

?

#

?

#

@cosmic quiver you there?

digital sun Apr 24, 2026, 10:23 PM

#

lll

digital sun Apr 24, 2026, 11:07 PM

#

hello

digital sun Apr 30, 2026, 2:22 AM

#

remember my discord stopped working and then you provided some solution which finally worked. Can you tell me what was it because again I have faced the same problem we had discord stopped working. Was it something related to the system clock going back because I just noticed that my system clock was like two hours back then it is actually.

digital sun Apr 30, 2026, 8:56 PM

#

hi

primal ivy Apr 30, 2026, 10:13 PM

#

I tried to troubleshoot a discord issue very similar. I ended up deleting the bot and discord config and doing from scratch again. Total time troubleshooting : 2 hours. Total time redoing : 10 minutes.

#discord stopped working..

1) Discord

2) Tailscale from Mac

Reliable fallback

What that means

Quick test on the Mac

Most likely fix

Immediate fallback

Immediate fallback