#Discord and Telegram both stopped responding today.

1 messages · Page 1 of 1 (latest)

spiral bronze Apr 23, 2026, 5:43 PM

Discord and telegram both stopped responding today. I need troubleshooting steps to take to fix this. I can still control it via remoting in through tail scale and control via the terminal so i'm looking for step by step instructions to get discord and telegram responding again.

chrome portalBOT Apr 23, 2026, 5:43 PM

manic gulchBOT Apr 23, 2026, 5:43 PM

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

lime sedgeBOT Apr 23, 2026, 5:45 PM

Let me check the actual docs so I don’t make up steps.

I found the troubleshooting runbook, now I’m locating the FAQ section the docs point to so I can give you the cleanest checklist.

Since both Discord and Telegram died the same day, I’d start with the shared layer first, meaning gateway health, logs, and network, not bot re-setup.

Use this order:

Get version first
```
openclaw --version
```
Quick snapshot
```
openclaw status --all
```
Check whether the gateway is actually alive

   openclaw gateway status

Run live logs
```
openclaw logs --follow
```
Probe channel state
```
openclaw channels status --probe
```
Run the repair/diagnostics pass

   openclaw doctor

What to look for

If gateway is stopped / timeout / unreachable

restart it:
```
openclaw gateway restart
```

then rerun:

openclaw gateway status
openclaw channels status --probe

If Telegram is failing
Look in logs for:

fetch failed
getUpdates failed
Polling stall detected
anything mentioning api.telegram.org

Then check DNS:

dig +short api.telegram.org A
dig +short api.telegram.org AAAA

Telegram stalls are often DNS/IPv6/proxy related. Docs specifically call out broken IPv6 egress as a common cause. If that’s what you see, that’s the branch I’d follow next.

If Discord is online but silent
Check for:

missing Message Content Intent
guild/channel allowlist mismatch
requireMention
DM pairing state

Useful checks:

openclaw pairing list discord
openclaw logs --follow

If Telegram is online but silent
Check:

openclaw pairing list telegram

Also verify group visibility/privacy mode if this is a group bot.

Best next move

Paste the output of these 4 commands and I can narrow it down fast:

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

Docs:

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

spiral bronze Apr 23, 2026, 6:00 PM

Summary from claude. I ran those steps here is the result:

SETUP: Mac Mini Apple Silicon, macOS 26.3, OpenClaw 2026.4.22, Node 22.22. Standard user lukeflaskamini (no sudo), admin user macadmin. OpenClaw via Homebrew/npm global. Config ~/.openclaw/openclaw.json. Workspace ~/.openclaw/workspace. Gateway loopback 127.0.0.1:18789, token auth, LaunchAgent loaded, pid active. Channels: Telegram @lucius_v1_bot + Discord @Lucius (guild FlasClaw Research Center 1471908142886555721), both enabled connected works. Auth: Anthropic Claude Max via claude setup-token (anthropic:default mode:token) AND openai-codex:lukeflaska@gmail.com (oauth). Default model openai-codex/gpt-5.4. Agents: main, codex-worker, sonnet-rescue, clawhub-test. Heartbeat anthropic/claude-haiku-4-5 55m interval. 4 agents, 41 sessions main.

PROBLEM: Bots not responding on Telegram or Discord since today. Channels probe healthy (Discord+Telegram show enabled,configured,running,connected,works). Gateway reachable. No channel-level failure.

ROOT CAUSE (from doctor + logs):

openai-codex:default EXPIRED (0m). Doctor says re-auth via openclaw models auth login --provider openai-codex.
Log error: [openai-codex] Token refresh failed: 401 {"message":"Your refresh token has already been used to generate a new access token. Please try signing in again.","type":"invalid_request_error","code":"refresh_token_reused"}
Prior OAuth attempt timed out: "OpenAI Codex OAuth callback did not arrive within 15000ms; switching to manual entry (callback_timeout)."

SECONDARY ISSUES:

Session agent:main:telegram:direct:8540189396 repeated context overflow on openai-codex/gpt-5.4, messages=335-336, compaction attempts failing/timing out. Log: "[timeout-compaction] LLM timed out with high prompt token usage (68%); attempting compaction" then "compaction did not reduce context... falling through to normal handling" then "surface_error reason=timeout." Session file ed9c6be8-0683-4a6a-ac05-d25a710270f0.jsonl.
Telegram polling stalls detected (132.95s no getUpdates), auto-recovering via forced restart cycles.
2 orphan transcript files in ~/.openclaw/agents/main/sessions (checkpoint+trajectory jsonl from session ed9c6be8).
3 unresolved Discord channels: 1471908144858005667, 1472629051238780992, 1488224070893047981.
2 other gateway-like LaunchAgents detected: ai.lucius.marathon, com.lucius.mission-control.
Plugin info: real-triage is hook-only, compatibility path not migrated.
MEMORY.md at 93% of per-file limit (20457/22000 chars). Total bootstrap 88% (52928/60000).
Exec config edit failed earlier: tried to change exec.security from "full" to "allowlist" but oldText didn't match (whitespace mismatch).

ATTEMPTED: openclaw gateway restart (successful, gateway reloaded clean). openclaw channels status --probe shows all green. openclaw doctor shows expired codex auth. openclaw status --all clean except expired auth.

QUESTIONS:

Correct command sequence to recover from refresh_token_reused on openai-codex? Is it just openclaw models auth login --provider openai-codex or do I need to first revoke/delete the stale profile?
How to handle the stuck Telegram session hitting context overflow - best way to reset or force-compact session 8540189396 without losing memory context? Can I delete the jsonl and have it start fresh on next message?
Should I fall back to anthropic/claude-sonnet-4-6 (already authed via claude setup-token) as default model until codex is stable? Command to swap default?
Are ai.lucius.marathon and com.lucius.mission-control safe to bootout, or are they expected custom services I set up?
Browser OAuth callback timed out last time (15s) - any flag to use manual code entry directly or extend timeout?
MEMORY.md near limit - recommended approach: bump agents.defaults.bootstrapMaxChars, or prune MEMORY.md content?

Goal: restore bot responses on both channels, prefer keeping codex as primary if possible, otherwise confirm sonnet fallback command.

What should I do next?

lime sedgeBOT Apr 23, 2026, 6:07 PM

I’m checking the exact commands so I don’t send you hand-wavy recovery steps.

One more pass on the auth/reset edge cases, then I’ll turn this into a clean fix sequence.

Yep, this looks like a model/auth failure, not a Discord or Telegram transport failure.

My recommendation is:

1. Restore replies first with Sonnet

Since Codex auth is expired, I’d temporarily move the default model off Codex now:

openclaw models set anthropic/claude-sonnet-4-6
openclaw models status

If you want to be extra sure the daemon picks it up immediately:

openclaw gateway restart

2. Re-auth Codex, don’t delete the profile first

For refresh_token_reused, the documented recovery is just:

openclaw models auth login --provider openai-codex

I would not start by hand-deleting auth-profiles.json. Doctor explicitly points to re-auth, and the login flow already clears stale auth lockout state before re-authing.

After login:

openclaw models status --probe-provider openai-codex
openclaw models auth order get --provider openai-codex

If it still prefers an old bad Codex profile, then clear the provider auth order:

openclaw models auth order clear --provider openai-codex

Only if that still looks wrong would I touch auth-profiles.json, and only after making a backup.

3. For the stuck Telegram session, don’t just delete the `.jsonl`

Safest answer: don’t delete only the transcript file while sessions.json still points at it.

Best path:

once replies are back, use /new or /reset in that Telegram chat, or
from terminal, back up the sessions dir, then remove the single session-store entry for agent:main:telegram:direct:8540189396, and archive the old transcript instead of hard-deleting it.

The docs say the session store is small/mutable and safe to edit or delete entries. So the safe terminal-side reset is:

cd ~/.openclaw/agents/main/sessions
cp sessions.json sessions.json.bak.$(date +%s)
mv ed9c6be8-0683-4a6a-ac05-d25a710270f0.jsonl ed9c6be8-0683-4a6a-ac05-d25a710270f0.jsonl.deleted.$(date +%s)
python3 - <<'PY'
import json, pathlib
p = pathlib.Path("sessions.json")
data = json.loads(p.read_text())
data.pop("agent:main:telegram:direct:8540189396", None)
p.write_text(json.dumps(data, indent=2) + "\n")
PY
openclaw gateway restart

That gives that chat a fresh session on the next inbound message, while keeping the old transcript around.

4. About `ai.lucius.marathon` and `com.lucius.mission-control`

I would not bootout those blindly.

They are not stock OpenClaw labels, so they’re probably custom or legacy services on your machine. First inspect them:

openclaw gateway status --deep
launchctl print gui/$(id -u)/ai.lucius.marathon 2>/dev/null | sed -n '1,120p'
launchctl print gui/$(id -u)/com.lucius.mission-control 2>/dev/null | sed -n '1,120p'

If either one is clearly an old duplicate OpenClaw gateway using the same config/port, then boot it out. If not, leave it alone.

5. OAuth callback timeout

I don’t see a user-facing flag for “force manual code entry” or “extend timeout”.

What the current Codex plugin does is:

wait 15s for localhost callback on 127.0.0.1:1455
if that fails, fall back to paste the redirect URL

So the practical recovery is just to run:

openclaw models auth login --provider openai-codex

…and when it prompts, paste the final http://localhost:1455/auth/callback?... URL from the browser.

6. `MEMORY.md`

I’d prune it, not raise limits first.

Docs explicitly recommend keeping injected files concise, especially MEMORY.md, because it burns context every turn. Move verbose/history stuff into memory/*.md or other non-bootstrap notes, and keep MEMORY.md to durable short bullets.

So, short version:

Immediate restore: switch default to Sonnet
Primary fix: re-auth Codex with openclaw models auth login --provider openai-codex
Telegram wedge: reset that one session key, don’t just delete the .jsonl
LaunchAgents: inspect first, don’t bootout blindly
MEMORY: prune, don’t increase caps yet

If you want, I can turn this into a copy-paste command sequence with “run this, expect this output, then run next”.

Do this in this order:

1. Get the bot replying again fast

Switch off Codex temporarily:

openclaw models set anthropic/claude-sonnet-4-6
openclaw gateway restart
openclaw models status

2. Re-auth Codex

In a real terminal on the Mac:

openclaw models auth login --provider openai-codex

If browser callback times out, paste the final localhost redirect URL when prompted.

Then verify:

openclaw models status --probe-provider openai-codex

3. If Telegram is still wedged after that, reset only that one session

Back it up first:

cd ~/.openclaw/agents/main/sessions
cp sessions.json sessions.json.bak.$(date +%s)
mv ed9c6be8-0683-4a6a-ac05-d25a710270f0.jsonl ed9c6be8-0683-4a6a-ac05-d25a710270f0.jsonl.deleted.$(date +%s)
python3 - <<'PY'

import json, pathlib
p = pathlib.Path("sessions.json")
data = json.loads(p.read_text())
data.pop("agent:main:telegram:direct:8540189396", None)
p.write_text(json.dumps(data, indent=2) + "\n")
PY
openclaw gateway restart

4. Test both surfaces

Send a DM/message in Telegram
Send a message in Discord
Watch logs live:

openclaw logs --follow

5. Ignore these for now

Not the first thing to touch:

ai.lucius.marathon
com.lucius.mission-control
MEMORY.md
unresolved Discord channel IDs

Those are cleanup items, not the fastest restore path.

If you want, paste the output from steps 1 and 2, and I’ll tell you exactly whether you need step 3.

spiral bronze Apr 23, 2026, 6:47 PM

RESOLVED: Bots not responding on Telegram + Discord.

Root cause: openai-codex OAuth had two profiles - stale "openai-codex:default" (expired, refresh_token_reused 401 error) and working "openai-codex:lukeflaska@gmail.com". The stale profile was "excluded by auth.order" and blocking routing. Channels themselves were healthy the whole time; LLM auth was the failure point.

Fix sequence that worked:

openclaw models auth login --provider openai-codex (re-authed via browser OAuth; callback timed out at 15s, used manual redirect URL paste)
openclaw gateway restart
Verified with: openclaw models status --probe --probe-provider openai-codex - showed both profiles still present, stale one still expired
Manually edited ~/.openclaw/agents/main/agent/auth-profiles.json - deleted the entire "openai-codex:default" block (including trailing comma) while leaving "openai-codex:lukeflaska@gmail.com" intact. (Note: no CLI logout subcommand exists - openclaw models auth only has add/login/login-github-copilot/order/paste-token/setup-token. Had to edit JSON directly.)
openclaw gateway restart
openclaw models status --probe --probe-provider openai-codex - confirmed single profile: openai-codex:lukeflaska@gmail.com ok, expires in 10d
Chmod 600 on auth-profiles.json and openclaw.json

Result: Default model anthropic/claude-sonnet-4-6 responds normally on both channels. Codex probe still times out at ~13s but that appears to be probe window limitation, not real failure - actual message routing works via fallback.

Open questions / remaining items:

Stuck Telegram session agent:main:telegram:direct:8540189396 still has 335+ message context overflow on codex. Not yet addressed. What's the clean way to reset or force-compact a single session without losing MEMORY.md context?
Is there a proper CLI command to remove a stale auth profile, or is manual JSON edit the expected approach?
Codex auth probe timeout of ~13s despite healthy token - is there a flag to extend probe timeout, or should this be ignored as long as real requests work?
Two orphan LaunchAgents still present (ai.lucius.marathon, com.lucius.mission-control) - unclear if these are legitimate custom services or leftovers needing cleanup.
MEMORY.md at 93% of per-file limit still unaddressed.

Feature request: CLI subcommand to delete/logout a specific auth profile (e.g. openclaw models auth remove --profile <id>) would prevent users needing to hand-edit JSON with live credentials in it.

lime sedgeBOT Apr 23, 2026, 6:49 PM

Nice, glad you got it back 🎉

For the remaining bits:

Single stuck Telegram session
Cleanest fix is /new in that Telegram chat now that the bot is replying again. That creates a fresh session for that session key and does not touch MEMORY.md.
I would use /new here, not /compact, because that session is already timing out during compaction.

If you need terminal-only recovery, the safe pattern is:
- back up ~/.openclaw/agents/main/sessions/sessions.json
- remove just agent:main:telegram:direct:8540189396 from it
- archive the matching .jsonl instead of deleting it
Removing a stale auth profile
I don’t see a real CLI delete/logout subcommand today. models auth order clear/set only changes routing order, it does not remove the stored profile.
So yes, manual edit of auth-profiles.json is currently the practical path.

Codex probe timeout
Yes, there’s a timeout flag:
```
openclaw models status --probe --probe-provider openai-codex --probe-timeout 30000
```
If real requests are working, I’d treat probe timeout as low priority.

Extra LaunchAgents
Those labels are not stock OpenClaw names, so don’t boot them out blindly. Inspect first:

openclaw gateway status --deep
launchctl print gui/$(id -u)/ai.lucius.marathon 2>/dev/null | sed -n '1,80p'
launchctl print gui/$(id -u)/com.lucius.mission-control 2>/dev/null | sed -n '1,80p'

Only remove them if they’re clearly duplicate gateway services.

MEMORY.md at 93%
I’d prune it before raising caps. Keep only durable facts in MEMORY.md, move historical/debug stuff into memory/*.md or another note. Bigger bootstrap files cost context every turn.