#After my agent displayed "Discord inbound worker timed out" in the Discord conversation, it stopped

1 messages · Page 1 of 1 (latest)

ancient raptor
#

This is a major setback for me. I am currently adjusting the sandbox and independent agents, but the issue mentioned in the title keeps occurring. It doesn't help whether I ask the agent to fix it in the main session or have Codex try to repair it. What should I do?

shut nebulaBOT
naive pagodaBOT
#

That message is usually a symptom, not the root cause.

It means Discord’s inbound worker gave up waiting for that turn. In practice, that usually means one of these is happening:

  • the agent run is hanging or blocked
  • it is waiting on a tool/approval and never finishes
  • your Discord timeout knobs were set too low while tuning sandbox/independent agents

Please paste these first:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe
openclaw logs --follow
#

Then trigger the problem once and grab the log lines around the timeout.

Also check whether you changed these Discord settings. A good baseline is:

  • channels.discord.accounts.default.eventQueue.listenerTimeout: 120000
  • channels.discord.accounts.default.inboundWorker.runTimeoutMs: 1800000

(single-account config has the same keys under channels.discord)

Important detail:

  • if logs mention Listener ... timed out after 30000ms, that is the listener budget
  • if logs mention discord inbound worker timed out after ..., that is the queued worker run timing out

So I would not keep asking the same Discord agent to fix itself from that thread. Debug it from the terminal first, then adjust the timeout or the underlying stuck run.

Docs:

ancient raptor
#

OpenClaw 2026.4.14 (323493f)

Gateway: unreachable (gateway closed (1008): pairing required)
Gateway service: running (pid 40852)
Node service: running (pid 40906)
Agents: 7 total, 1 active, 119 sessions
Channels:
Discord ON / OK
LINE ON / OK

Dashboard: http://127.0.0.1:18789/
Config: ~/.openclaw/openclaw.json
OS: macos 26.4.1 (arm64)
Node: 24.14.0

Runtime: running (pid 40852, state active)
Listening: 127.0.0.1:18789
RPC probe: failed
gateway closed (1008): pairing required
Service config issue:
Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled.
Suggested fix: openclaw gateway install --force

Checking channel status (probe)…
gateway closed (1008): pairing required

Config-only status:
Discord default: enabled, configured, token:config
LINE default: enabled, configured, mode:webhook, token:env

lane wait exceeded:
waitedMs=14270 queueAhead=0
waitedMs=14688 queueAhead=0
waitedMs=5164 queueAhead=0

2026-04-17T01:43:51.494+08:00 [discord] connect error: pairing required
2026-04-17T01:44:34.105+08:00 [ws] unauthorized ... reason=rate_limited
2026-04-17T01:44:37.627+08:00 [ws] closed before connect ... reason=unauthorized: too many failed authentication attempts (retry later)
2026-04-17T01:45:02.422+08:00 [ws] closed before connect ... reason=pairing required
2026-04-17T02:42:42.880+08:00 [ws] closed before connect ... reason=pairing required

2026-04-17T02:42:22~02:42:26 [ws] res ✓ sessions.list / chat.history / models.list

naive pagodaBOT
#

This looks more like gateway auth drift than a sandbox/Codex bug.

The big clues are:

  • gateway closed (1008): pairing required
  • unauthorized: too many failed authentication attempts
  • Gateway service embeds OPENCLAW_GATEWAY_TOKEN and should be reinstalled

So I would treat the Discord timeout as downstream of the gateway not authenticating cleanly.

Do this in order

  1. On macOS, clear any old launchctl auth overrides
launchctl getenv OPENCLAW_GATEWAY_TOKEN
launchctl getenv OPENCLAW_GATEWAY_PASSWORD
# 
launchctl unsetenv OPENCLAW_GATEWAY_TOKEN
launchctl unsetenv OPENCLAW_GATEWAY_PASSWORD
  1. Rewrite the gateway service, then restart it
openclaw gateway install --force
openclaw gateway restart
  1. Approve the pending device pairing
openclaw devices list
openclaw devices approve <requestId>
#
  1. If the same browser/device is stale, re-pair it
openclaw devices list
openclaw devices remove <deviceId>
openclaw devices list
openclaw devices approve <requestId>

  1. Wait a minute before hammering reconnect again
    You already hit the auth rate limiter, so give it a short cooldown after fixing the token/pairing side.

  2. Re-check

openclaw status
openclaw gateway status
openclaw channels status --probe
#

Why I think this is the right path

Your gateway is running, but local RPC is failing on auth/pairing. If the worker cannot complete its internal gateway calls cleanly, the Discord turn can sit there until it eventually times out.

If you want, paste the next outputs from:

openclaw devices list
openclaw gateway status
openclaw status

after steps 1 to 3, and I’ll help check the next layer.

Docs: