Discord "Agent couldn't generate a response"

[silk yoke]

Yesterday my OpenClaw Assistant stopped responding, instead saying "Agent couldn't generate a response".

I've completely reconfigured my Discord connection multiple times. Occasionally I can get a test message through via a separate OpenClaw Agent I have trying to debug it for me. Most of the time the test fails, but every once in awhile it is able to message me. I still cannot respond, same error.

I've tried using different models as well. The TUI and dashboard work fine. It's just Discord.

Latest version of CachyOS w/ COSMIC
Lastest build of OpenClaw

[stiff bluff]

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

[timid shore]

Quick check in the docs and source so I don’t make up config keys.

That specific message is the generic incomplete-turn fallback, not a Discord auth error by itself.

Since TUI and dashboard still work, I’d focus on the Discord path/session first, not the model.

First, what version are you on?

openclaw --version

Then reproduce one failed Discord reply and grab:

openclaw status --all
openclaw channels status --probe
openclaw logs --follow

A few likely causes here:

• stale/corrupted Discord session history
  Try /new once in the broken Discord conversation.

• Discord timeout on inbound handling
  Look for:

  • Listener DiscordMessageListener timed out...
  • discord inbound worker timed out...

• guild policy / mention / allowlist / permission issue
  Look for:

  • mention required
  • blocked / allowlist
  • 401, 403, Forbidden

If this is happening in DMs, also run:

openclaw pairing list --channel discord

If you paste back:

1. openclaw --version
2. openclaw channels status --probe
3. the log lines from one failed reply

…I can narrow it down pretty fast.

Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/help/troubleshooting
https://docs.openclaw.ai/channels/discord

[silk yoke]

`❯ openclaw --version
OpenClaw 2026.4.15 (041266a)

~
❯ openclaw channels status --probe
openclaw health

🦞 OpenClaw 2026.4.15 (041266a) — I'm not AI-powered, I'm AI-possessed. Big difference.

│
◇
Gateway reachable.

• Discord default: enabled, configured, running, connected, in:3m ago, bot:@Durandal, token:config, intents:content=limited, works

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

🦞 OpenClaw 2026.4.15 (041266a) — I'll butter your workflow like a lobster roll: messy, delicious, effective.

│
◇
Discord: ok (@Durandal) (3176ms)
Agents: main (default), leela-discord, durandal-discord
Heartbeat interval: disabled (main)
Session store (main): /home/pfhor/.openclaw/agents/main/sessions/sessions.json (29 entries)

• agent:main:main (7m ago)
• agent:main:discord:direct:84218891609309184 (21m ago)
• agent:main:cron:b6e2bf23-6208-4032-8585-d140577b8c4f (32m ago)
• agent:main:cron:b6e2bf23-6208-4032-8585-d140577b8c4f:run:07625825-a9b3-47f8-8096-c6105f01cb6d (32m ago)
• agent:main:cron:b6e2bf23-6208-4032-8585-d140577b8c4f:run:efbac270-f0a4-4e2d-973c-aee0b9d0626b (93m ago)`

[timid shore]

Nice, this narrows it down a lot.

Your version is current enough, and channels status --probe says Discord is connected and works, so I would stop reconfiguring Discord. That part looks healthy.

At this point the two things I’d suspect most are:

1. stale/corrupted Discord session history
2. Discord inbound timeout

Try this first

In the broken Discord DM/thread, send a standalone:

/new

Then send a tiny plain-text message like hi.

That generic "Agent couldn't generate a response" fallback often happens when the session history is bad.

If it still fails

Run this in a terminal:

openclaw logs --follow

Then reproduce one failed Discord reply and paste the relevant log lines.

The log signatures that matter most are:

• Listener DiscordMessageListener timed out...
• discord inbound worker timed out...
• messages.content.tool_use.input field required
• mention required

• blocked / allowlist
• 401 / 403 / Forbidden

If you see a Discord timeout

Set the listener timeout higher and restart the gateway:

{
  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: {
            listenerTimeout: 120000,
          },
        },

      },
    },
  },
}

One extra note: your probe shows intents:content=limited. That is fine for DMs and mention-based use, but if the failures are in guild channels too, mention the bot or enable Message Content Intent.

Docs:
https://docs.openclaw.ai/channels/discord
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting

If you paste the openclaw logs --follow lines from one failed attempt, I can usually tell which branch this is pretty quickly.

[silk yoke]

21:42:57+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=fdd3ad94-5664-469e-b2bc-f81718c8cf40 sessionId=cb4af041-a3ba-4622-b0ce-51d223924325 stopReason=stop payloads=0 — surfacing error to user

[timid shore]

Yep, that’s the smoking gun.

stopReason=stop payloads=0 means the run finished normally, but the model produced no user-visible reply at all. So this looks much less like Discord auth/transport, and much more like a bad session/history state in that Discord conversation.

Most likely fix

In the broken Discord DM/thread, send a standalone:

/new

Then send a tiny test like:

hi

That warning is exactly the kind of thing I’d expect from a stale/corrupted session.

Important detail

The line you pasted is the final symptom, not the root cause.
If /new does not fix it, I want the 10 to 20 log lines immediately before that warning, because the real clue is usually earlier.

What I’d do next

1. Try /new
2. If it still fails, run:

   openclaw logs --follow
   

3. Reproduce once
4. Paste the lines right before the incomplete turn detected... payloads=0 warning

If /new fixes it, and this tends to come back on long Discord threads, the follow-up is usually session pruning / compaction tuning:
https://docs.openclaw.ai/concepts/session-pruning

https://docs.openclaw.ai/concepts/compaction

So, honestly, I’d try /new first before touching Discord config again.

[silk yoke]

/new doesn't work either. It just gives me the same error.

Trying / new gives me the same result

21:56:59+00:00 warn skills {"subsystem":"skills"} {"source":"openclaw-managed","rootDir":"/home/pfhor/.openclaw/skills","rootRealPath":"/home/pfhor/.openclaw/skills","path":"/home/pfhor/.openclaw/skills/freeride","realPath":"/home/pfhor/.agents/skills/freeride","reason":"symlink-escape"} Skipping escaped skill path outside its configured root. 21:57:02+00:00 info hooks/session-memory {"subsystem":"hooks/session-memory"} Session context saved to ~/.openclaw/workspace/memory/2026-04-19-durandal-discord.md 21:57:02+00:00 warn skills {"subsystem":"skills"} {"source":"openclaw-managed","rootDir":"/home/pfhor/.openclaw/skills","rootRealPath":"/home/pfhor/.openclaw/skills","path":"/home/pfhor/.openclaw/skills/freeride","realPath":"/home/pfhor/.agents/skills/freeride","reason":"symlink-escape"} Skipping escaped skill path outside its configured root. 21:57:02+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 203ms conn=1d4e4b7e…309b id=2974b3c1…9bdb 21:57:03+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=23cebb5b-373d-4d68-9db6-11c6e59251bf sessionId=ccbc7242-1071-4644-a5ff-483f720da859 stopReason=stop payloads=0 — surfacing error to user

[timid shore]

Let me check the docs/source for that session-memory hook and the escaped skill warning before I point you in the wrong direction.

That helps.

Two important takeaways from those logs:

1. session-memory is normal for /new, not the bug.
2. symlink-escape is a real misconfig:
   OpenClaw is refusing to load ~/.openclaw/skills/freeride because it resolves outside that managed root.

Supported skill roots already include ~/.agents/skills, so that symlink setup is unnecessary and now gets blocked. I’d clean that up separately.

But the actual failure is still this:

stopReason=stop payloads=0

That means the run is ending with an empty assistant turn. Since:

• Discord transport probes healthy
• /new did not fix it
• TUI/dashboard still work

…I think you’re probably in bug/regression territory, not simple Discord config trouble.

My recommendation

1. Remove or disable that broken freeride symlinked skill and retry once
   (just to eliminate the one obvious bad thing in the logs)

2. If it still happens, please file a GitHub issue with:

   • openclaw --version
   • openclaw channels status --probe
   • the stopReason=stop payloads=0 log line
   • note that /new did not help

Issue tracker:

https://github.com/openclaw/openclaw/issues

Skill docs, for the symlink bit:
https://docs.openclaw.ai/tools/skills
https://docs.openclaw.ai/help/faq

If you can grab 20-ish lines before that incomplete turn detected line too, that would make the issue report a lot stronger.

[silk yoke]

I deleted the skill both manually by deleting the folder, and I disabled it in the dashboard. Despite deleting it, it's still showing up in the list. Still having the same issue. I'll grab more logs in a moment.

[timid shore]

One quick thing before you dig more: that warning points at a symlink target under ~/.agents/skills/freeride, not just ~/.openclaw/skills/freeride. Let me verify the exact skills commands so I don’t send you on a goose chase.

Ah, that part makes sense now.

OpenClaw loads skills from both:

• ~/.openclaw/skills
• ~/.agents/skills

Your earlier warning showed the real path as:

~/.agents/skills/freeride

So deleting only the ~/.openclaw/skills/... side would not fully remove the underlying copy if it still exists there, and the gateway may also just need a restart to drop stale state.

I’d do these next

openclaw skills list --verbose
openclaw gateway restart

Also check whether this still exists:

~/.agents/skills/freeride

If freeride still shows up after the restart, paste the relevant openclaw skills list --verbose lines. That will tell us exactly which skill root it’s coming from.

I still suspect the skill warning is separate from the empty-turn bug, but cleaning it up will make the next log dump way more useful.

Docs:
https://docs.openclaw.ai/tools/skills

And yep, send the extra logs when you have them.

[silk yoke]

I removed freeride entirely now, but I'm having the same issue.

`22:40:19+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 220ms conn=1d739fb3…626f id=a4081046…2154
22:40:19+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 221ms conn=1d739fb3…626f id=2b39b2a5…f429
22:40:35+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2164ms conn=1d739fb3…626f id=4e07eeff…a66d
22:40:36+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2079ms conn=4c423059…c0bf id=36c0b826…a331
22:40:39+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2052ms conn=1d739fb3…626f id=da78ccff…6b2a
22:40:40+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2061ms conn=4c423059…c0bf id=55ec4002…57f9
22:40:54+00:00 info cron {"module":"cron","storePath":"/home/pfhor/.openclaw/cron/jobs.json"} {"pruned":1,"retentionMs":86400000} cron-reaper: pruned 1 expired cron run session(s)
22:41:35+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2056ms conn=1d739fb3…626f id=a1bdb7a7…da4d
22:41:36+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2011ms conn=4c423059…c0bf id=623ddd5a…73df
22:41:39+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2014ms conn=1d739fb3…626f id=ce6e7936…c978
22:41:40+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 2197ms conn=4c423059…c0bf id=a2e6d9c6…095f
22:41:51+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=3fbece1c-50ed-4834-ae28-b807690c46d2 sessionId=c9c4e4ec-16e2-4346-9927-607f44623d32 stopReason=stop payloads=0 — surfacing error to user
22:41:51+00:00 info ⚠️ Agent couldn't generate a response. Please try again.
22:41:51+00:00 info ⚠️ Agent couldn't generate a response. Please try again.
Log tail truncated (increase --max-bytes).
22:42:14+00:00 warn agent/embedded {"subsystem":"agent/embedded"} incomplete turn detected: runId=b3408149-0f1b-4917-aa8a-f1ba1a1c5c52 sessionId=c9c4e4ec-16e2-4346-9927-607f44623d32

stopReason=stop payloads=0 — surfacing error to user
22:42:14+00:00 info ⚠️ Agent couldn't generate a response. Please try again.'

[timid shore]

Thanks, that’s actually useful. It pretty much clears freeride as a red herring.

At this point I want the full failure window, not just the last line.

Please do:

openclaw logs --follow

Then reproduce one failed Discord reply and paste either:

• the first line mentioning that runId, through the incomplete turn detected line, or
• about 20 to 30 lines before the warning

The important part is whatever happens before:

stopReason=stop payloads=0

If the next dump still shows no upstream error and just another empty turn, I’d go ahead and file a GitHub issue, because that starts looking like a real Discord-side regression rather than a config mistake:

https://github.com/openclaw/openclaw/issues
https://docs.openclaw.ai/gateway/troubleshooting

If you paste the next log chunk here, I’ll help narrow it down.

The tail is still cutting off the useful part. I’m checking the exact logs flags so I can ask for the right command instead of guessing.

Yep, this is still clipped too hard.

A couple of those lines are just background noise:

• node.list / device.pair.list = dashboard / control traffic
• the duplicate ⚠️ Agent couldn't generate a response lines = the fallback being logged/sent

The part we still don’t have is whatever happened right before the empty turn.

Better command

Right after reproducing one failure, run:

openclaw logs --limit 200 --max-bytes 200000 --plain

If that still truncates, bump --max-bytes higher.

Then paste the chunk around the newest runId, ideally 10 to 20 lines before:

runId=b3408149-0f1b-4917-aa8a-f1ba1a1c5c52

That should finally show whether this is:

• an upstream provider/model error,
• a filtered empty assistant reply,
• or a real OpenClaw Discord regression.

If the bigger dump still shows nothing except stopReason=stop payloads=0, I’d stop digging and file the bug:
https://github.com/openclaw/openclaw/issues

Yep, that’s still only the fallback, not the root cause.

At this point I’d stop burning time on Discord reconfiguration and file a bug. The evidence is pretty solid now:

• OpenClaw 2026.4.15
• Discord probe says connected / works
• TUI and dashboard are fine
• /new did not help
• removing freeride did not help
• Discord turns end with stopReason=stop payloads=0

Please file here:
https://github.com/openclaw/openclaw/issues

You can pretty much paste this:

OpenClaw 2026.4.15 on CachyOS/COSMIC.

Discord transport probes healthy (`openclaw channels status --probe` shows connected/works), but Discord conversations fail with:

`incomplete turn detected ... stopReason=stop payloads=0`

The user sees:
`⚠️ Agent couldn't generate a response. Please try again.`

TUI and dashboard still work.
`/new` does not fix it.
Removing a broken custom skill (`freeride`) did not fix it either.

If you want, I can help you turn that into a cleaner GitHub issue body before you post it.

[silk yoke]

Please do

[timid shore]

Yep, here’s a ready-to-paste GitHub issue.

Title

Discord replies fail with "Agent couldn't generate a response" while TUI/dashboard work, logs show stopReason=stop payloads=0

Body

## Summary

Since yesterday, my OpenClaw assistant on Discord stopped responding and now says:

> Agent couldn't generate a response

TUI and dashboard still work fine. This seems isolated to Discord.

## Environment

- OpenClaw: `2026.4.15 (041266a)`
- OS: CachyOS
- Desktop: COSMIC

## What I tried

- Reconfigured the Discord connection multiple times
- Tried different models
- Tried `/new`
- Removed a broken custom skill (`freeride`) entirely
- Restarted / re-tested after cleanup

None of that changed the behavior.

## Current behavior

- Discord transport appears healthy
- I can occasionally get a test message through from another OpenClaw agent
- But replying still fails with:
  - `⚠️ Agent couldn't generate a response. Please try again.`

## Expected behavior

Discord replies should behave the same as TUI/dashboard and return a normal assistant response.

## Diagnostics

`openclaw channels status --probe` shows Discord is connected and working:

```text
OpenClaw 2026.4.15 (041266a)

Gateway reachable.
- Discord default: enabled, configured, running, connected, in:3m ago, bot:@Durandal, token:config, intents:content=limited, works

Discord: ok (@Durandal) (3176ms)
Agents: main (default), leela-discord, durandal-discord
Heartbeat interval: disabled (main)
Session store (main): /home/pfhor/.openclaw/agents/main/sessions/sessions.json
- agent:main:discord:direct:84218891609309184

Relevant logs:

```text
warn agent/embedded incomplete turn detected: runId=... sessionId=... stopReason=stop payloads=0 — surfacing error to user
info ⚠️ Agent couldn't generate a response. Please try again.

I also saw this repeatedly before removing the custom skill, but removing it did not fix the issue:

warn skills ... Skipping escaped skill path outside its configured root ... reason="symlink-escape"

Notes

- TUI works
- Dashboard works
- Discord does not
- `/new` does not fix it
- Removing the broken skill does not fix it

This looks like Discord-specific empty-turn behavior, or some Discord-path regression where the run ends with `stopReason=stop` and no payloads.

If you post that, it should be enough for a maintainer to take it seriously.

[silk yoke]

Thank you for your help, @timid shore

[timid shore]

Of course, happy to help 🦐

I’m glad we narrowed it down at least. If you get a response on the GitHub issue or find the actual culprit, feel free to drop it back here. That’ll help the next person too.

[silk yoke]

I am still having this issue, if anyone else happens to have any ideas