Openclaw 2026.5.16-beta.6 with OpenRouter doesn't send back messages

[wary hound]

I bumped 2026.5.12 to 2026.5.16-beta.6 to get some fixes (specially the verbose for discord) but all messages doesn't seems to come trough tho the request is well made on OpenRouter and sent back with a completion...

[digital ledge]

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

[unkempt anvil]

That sounds like the model/provider leg is succeeding and the failure is later in Discord reply delivery/finalization.

First checks I’d run:

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

Then send one Discord test message and look in the logs for discord stream preview, dispatchReply, sendMessageDiscord, DiscordAPIError, Missing Access, or anything mentioning block/preview delivery.

Because 2026.5.16-beta.6 has recent Discord preview/block-streaming changes, a useful quick workaround is to disable Discord streaming/preview and restart the gateway, then test again:

openclaw config set channels.discord.streaming.mode off

[unkempt anvil]

openclaw gateway restart

If replies come back with streaming off, that’s a pretty clean beta regression signal. In that case I’d file it with the version, provider/model route, and the redacted log tail here: https://github.com/openclaw/openclaw/issues

Docs for the generic triage ladder are here: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/gateway/troubleshooting

[wary hound]

openclaw channels status --probe

Gateway reachable.

• Discord default: enabled, configured, running, connected, in:4m ago, bot:@Koda, token:config, intents:content=limited, works, audit ok
  Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

I restarted and put the streaming to off

openclaw logs --follow

10:56:24+02:00 info channels/discord {"subsystem":"channels/discord"} discord client initialized as 1471512487328350433; awaiting gateway readiness
10:57:26+02:00 warn Config warnings:

• plugins.entries.memory-openmemory: plugin disabled (disabled in config) but config is present
  10:57:36+02:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ logs.tail 75ms conn=9386dfe1…f9f6 id=e26d6ec2…b198
  On discord :
  stanouctn 🥔 [NJZ], — 10:57
  Ok et là tu fais quoi ?
  Koda APP — 10:57
  ✉️ Message
  (but no messages)

[unkempt anvil]

Thanks, that narrows it down. Since channels status --probe says works, audit ok and Koda can post the ✉️ Message status, Discord send permissions are probably fine. Streaming being off also makes the preview path less likely.

That ✉️ Message line is suspicious: it usually means the agent/tool-progress path reached the message tool. In a Discord group/thread reply, OpenClaw should normally send the final reply automatically, not rely on the model using message to the same target. If the model/tool call errored or sent an empty payload, the final can look like it vanished.

Two things I’d try next:

# beta.7 is shown as available in your status output, and beta.6 is in the churny Discord/block-streaming area
pnpm openclaw update --channel beta
openclaw gateway restart

Then reproduce once and grab the actual agent/send log lines, not just startup:

LOG=$(ls -t /tmp/openclaw/openclaw-*.log | head -1)

[unkempt anvil]

rg -n "Message must be non-empty|sendMessageDiscord|DiscordAPIError|message tool|reply_dispatch|runReplyAgent|OpenRouter|tool" "$LOG" | tail -120

Also worth fixing separately: the probe says intents:content=limited. Discord docs say Message Content Intent is required for guild/channel use, so enable Message Content Intent in the Discord Developer Portal → Bot → Privileged Gateway Intents, then restart the gateway. It may not be the whole cause here because Koda is seeing enough to react, but it’s still a bad baseline.

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

[wary hound]

I checked the intents it has it, and I restarted again and on a new session, it does the same, though it does all the tools calling.

After 3 user prompts, it finally sent a message

[unkempt anvil]

Yep, this log changes the diagnosis. Intents/Discord transport are not the main problem.

The key line is:

EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released

That means the agent turn is losing its session-file lock while the model/tool loop is running. Then OpenClaw marks the primary candidate failed and falls back:

candidate_failed ... openrouter/google/gemini-3-flash-preview
next=openrouter/google/gemini-3.1-flash-lite-preview

So the “does all the tool calls but doesn’t reply” behavior is likely session/write-lock + fallback weirdness, not Discord permissions. The event_loop_delay,cpu warning also says the gateway was under heavy CPU/event-loop pressure at the same time, which can make this kind of lock timing issue easier to trigger.

[unkempt anvil]

I’d do these in order:

openclaw update --channel beta
openclaw --version
openclaw gateway restart

Your earlier status already showed 2026.5.16-beta.7 available, and current changelog has multiple Discord final-delivery/progress-draft fixes after the beta.6 area.

If beta.7+ still reproduces, this is GitHub-issue material. Include:

• version from openclaw --version
• the EmbeddedAttemptSessionTakeoverError lines
• the fallback lines
• mention it happens with openrouter/google/... after tool calls and sometimes only replies after repeated prompts

[unkempt anvil]

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

For a temporary workaround, try a different provider route/model family for the Discord agent, or reduce concurrent prompts/tool-heavy turns, because the failing path here is the active session being modified mid-turn. Also: content=limited is less concerning now if the intent is enabled and channels status --probe says works, audit ok.

[wary hound]

openclaw --version
OpenClaw 2026.5.16-beta.7 (fff4532)

I still have the issue... 🙁

[unkempt anvil]

Ah, beta.7 is still behind at least one fix that looks very relevant here.

I checked current main, and after v2026.5.16-beta.7 there’s this fix:

1e5450f23e fix(messages): keep group visible replies automatic by default (#83498)

That matches your symptom pretty closely: Discord thread/group turn runs tools, but the visible final reply is unreliable/missing.

So I’d treat this as a beta.7 bug, not your Discord setup. Two practical options:

# if you’re okay testing current main/dev bits
openclaw update --tag main
openclaw gateway restart

[unkempt anvil]

or wait for the next beta that includes that fix.

If main still reproduces, then please file it with the EmbeddedAttemptSessionTakeoverError log and mention that beta.7 still misses visible Discord thread replies after tool calls: https://github.com/openclaw/openclaw/issues

Update docs for the channel/tag behavior: https://docs.openclaw.ai/install/development-channels

[wary hound]

Ok I'll wait the next beta, can you find a safe spot where I can go back ?

[unkempt anvil]

Safest rollback spot is 2026.5.12.

Reason: you already had it working, and it’s the latest stable tag before the 2026.5.14/2026.5.16 beta Discord progress/final-delivery churn. I’d avoid 2026.5.14-beta.* as a rollback target because it’s still a beta lane between the known-good and the broken range.

For a package/pnpm install, do:

openclaw update --tag 2026.5.12 --dry-run
openclaw update --tag 2026.5.12 --yes
openclaw gateway restart
openclaw --version

If you want a quick safety copy first:

[unkempt anvil]

cp -a ~/.openclaw ~/.openclaw.backup-before-rollback-$(date +%Y%m%d-%H%M%S)

One nuance: --tag is a one-off and won’t change your saved update channel. So after rolling back, don’t run plain openclaw update until the next beta/stable you want is out. When you’re ready to move forward again:

openclaw update --channel beta

Docs: https://docs.openclaw.ai/install/development-channels

[wary hound]

With 2026.5.12 I have thoses back -_- that's why I was wondering if there was a safe spot

16:03:41 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3-flash-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:03:45 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3-flash-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:03:52 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3-flash-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:04:03 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3-flash-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:04:03 [agent/embedded] embedded run failover decision: runId=57b31c47-b24c-42b6-a08a-b556c51389ab stage=assistant decision=fallback_model reason=timeout from=openrouter/google/gemini-3-flash-preview profile=- rawError=500 Internal Server Error
16:04:03 [diagnostic] lane task error: lane=main durationMs=26902 error="FailoverError: HTTP 500: Internal Server Error"
16:04:03 [diagnostic] lane task error: lane=session:agent:main:discord:channel:1505903005621289051 durationMs=26917 error="FailoverError: HTTP 500: Internal Server Error"
16:04:03 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openrouter/google/gemini-3-flash-preview candidate=openrouter/google/gemini-3-flash-preview reason=timeout next=openrouter/google/gemini-3.1-flash-lite-preview detail=500 Internal Server Error
16:04:07 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3.1-flash-lite-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:04:11 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3.1-flash-lite-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:04:17 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3.1-flash-lite-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:04:27 [agent/embedded] embedded run agent end: runId=57b31c47-b24c-42b6-a08a-b556c51389ab isError=true model=google/gemini-3.1-flash-lite-preview provider=openrouter error=HTTP 500: Internal Server Error rawError=500 Internal Server Error
16:04:27 [agent/embedded] embedded run failover decision: runId=57b31c47-b24c-42b6-a08a-b556c51389ab stage=assistant decision=fallback_model reason=timeout from=openrouter/google/gemini-3.1-flash-lite-preview profile=- rawError=500 Internal Server Error
16:04:27 [diagnostic] lane task error: lane=main durationMs=24541 error="FailoverError: HTTP 500: Internal Server Error"
16:04:27 [diagnostic] lane task error: lane=session:agent:main:discord:channel:1505903005621289051 durationMs=24550 error="FailoverError: HTTP 500: Internal Server Error"
16:04:27 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=openrouter/google/gemini-3-flash-preview candidate=openrouter/google/gemini-3.1-flash-lite-preview reason=timeout next=openrouter/minimax/minimax-m2.7 detail=500 Internal Server Error

[unkempt anvil]

Yeah, fair. 2026.5.12 is not a safe rollback for your current OpenRouter/Gemini route.

I checked the tags against the relevant fixes. The rough picture is:

2026.5.12          no Gemini tool-signature fixes, no group visible-reply fix
2026.5.16-beta.5  has first Gemini tool-signature fix, but not the group visible-reply fix
2026.5.16-beta.6  has more Gemini fix, but still not the group visible-reply fix
2026.5.16-beta.7  same problem for visible replies
2026.5.18-beta.1  has both Gemini fixes and the group visible-reply fix

So the safest spot I’d try is actually forward to the new beta, not back:

openclaw update --tag 2026.5.18-beta.1 --dry-run

[unkempt anvil]

openclaw update --tag 2026.5.18-beta.1 --yes
openclaw gateway restart
openclaw --version

If you absolutely need to stay on 2026.5.12, I’d avoid openrouter/google/gemini-3-*-preview there and temporarily switch that agent to a non-Gemini OpenRouter model route, because those 500s look like the older Gemini/tool replay bug path.

Docs for pinning one version: https://docs.openclaw.ai/install/development-channels

[wary hound]

2026.5.18-beta.1 doesn't exists, 2026.5.16-beta.6 seems to be working pretty decently, I just have an incessant fallback switches and multiple answers to my prompt but at least it is responding 😄

[unkempt anvil]

Yeah, that makes sense. I checked git tags, but if the npm/package update path can’t see 2026.5.18-beta.1, then for your install it effectively doesn’t exist yet. My bad for assuming the git tag was installable via your updater.

Given what you’re seeing, I’d treat 2026.5.16-beta.6 as the least-bad safe spot for now: it has the Gemini/OpenRouter fixes you need, and it replies. The annoying part now is the fallback chain.

To reduce the fallback switching + duplicate/multiple answers, temporarily pin one model and remove fallbacks:

openclaw config get agents.defaults.model
openclaw config set agents.defaults.model '{"primary":"openrouter/google/gemini-3-flash-preview","fallbacks":[]}' --strict-json
openclaw gateway restart

If that route is the flaky one, use whichever single route has been most reliable for you as primary instead. The important bit is "fallbacks":[] so it doesn’t keep bouncing through candidates and producing weird retry-visible behavior.

After changing it, start a fresh Discord session/thread or run /new, because the current session may already have a fallback override persisted.

When the next beta is actually available through your updater, you can check without applying it:

[unkempt anvil]

openclaw update --tag beta --dry-run
openclaw update --channel beta --dry-run

Fallback docs: https://docs.openclaw.ai/concepts/model-failover

[wary hound]

Is it really useful to have fallbacks on OpenRouter ? I mean OR is already a big fallback, I could just put models for my agents without fallbacks

[unkempt anvil]

Yes, that instinct is reasonable.

For OpenRouter specifically, I’d usually keep OpenClaw fallbacks minimal or disabled unless you have a clear reason. OpenRouter already does routing/provider abstraction, and stacking OpenClaw model fallback on top can make failures harder to reason about: one flaky upstream turns into cooldowns, session model overrides, repeated retries, and sometimes multiple visible replies when a beta has delivery bugs.

My practical recommendation:

• For each agent, set one primary model route you trust.
• Use no OpenClaw fallbacks for normal Discord chat/tool agents while this beta issue is active.
• Add fallbacks only when they are intentionally different, e.g. a cheaper backup, a non-OpenRouter provider, or a model with different capabilities.
• If you want OpenRouter’s own auto-routing behavior, prefer configuring that directly rather than also layering OpenClaw fallbacks.

So yes, “models per agent without fallbacks” is a clean setup here.

Config shape:

[unkempt anvil]

agents: {
  defaults: {
    model: {
      primary: "openrouter/your/chosen-model",
      fallbacks: [],
    },
  },
}

And for current model quality/route picks, #models is still the better place because OpenRouter routes change fast. Docs: https://docs.openclaw.ai/concepts/model-failover and https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

[wary hound]

Ok but I still have locks error is it fixed in the latest tag ?

17:01:59 [fetch-timeout] fetch timeout after 10000ms (elapsed 10001ms) operation=fetchWithTimeout url=https://discord.com/api/v10/users/@me
17:02:34 [diagnostic] liveness warning: reasons=event_loop_delay,cpu interval=62s eventLoopDelayP99Ms=1245.7 eventLoopDelayMaxMs=33722.2 eventLoopUtilization=0.871 cpuCoreRatio=0.922 active=1 waiting=0 queued=0 recentPhases=sidecars.subagent-recovery:43ms,sidecars.main-session-recovery:18ms,sidecars.restart-sentinel:95ms,post-attach.update-sentinel:21ms,sidecars.session-locks:168ms,post-ready.maintenance:220ms work=[active=agent:main:discord:channel:1505903005621289051(processing/embedded_run,q=1,age=52s last=embedded_run:started)]
17:02:34 [discord] gateway: Gateway websocket closed: 1000
17:02:34 [agent/embedded] [trace:embedded-run] prep stages: runId=8acae878-0c00-45c5-8c95-fdb143993da9 sessionId=91ff47fe-b6ee-467e-9944-f1df3636eb87 phase=stream-ready totalMs=37067 stages=workspace-sandbox:7ms@7ms,skills:3ms@10ms,core-plugin-tools:1771ms@1781ms,bootstrap-context:181ms@1962ms,bundle-tools:184ms@2146ms,system-prompt:635ms@2781ms,session-resource-loader:34124ms@36905ms,agent-session:23ms@36928ms,stream-setup:139ms@37067ms
17:02:43 [diagnostic] lane task error: lane=main durationMs=7687 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/f402570c-a4fc-428e-a8ee-510f2f8d82dc-topic-1505948524154585271.jsonl"
17:02:43 [diagnostic] lane task error: lane=session:agent:main:discord:channel:1505948524154585271 durationMs=7697 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/f402570c-a4fc-428e-a8ee-510f2f8d82dc-topic-1505948524154585271.jsonl"
17:02:43 Embedded agent failed before reply: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/f402570c-a4fc-428e-a8ee-510f2f8d82dc-topic-1505948524154585271.jsonl

[unkempt anvil]

Short answer: I don’t see a clear lock fix in the latest published npm beta.

I checked npm just now:

latest = 2026.5.12
beta   = 2026.5.16-beta.7

There is a git tag v2026.5.18-beta.1, but it isn’t the npm beta your updater sees. That git tag includes the Discord visible-reply fix, but I don’t see an obvious EmbeddedAttemptSessionTakeoverError/session-lock fix in that tag.

This log also has two extra signals:

session-resource-loader:34124ms
liveness warning: event_loop_delay,cpu

[unkempt anvil]

So the gateway is heavily delayed before the run even starts streaming. The lock error can happen if the same session file is modified while the embedded model call has released the prompt lock. Common causes:

• two OpenClaw gateways/processes/containers touching the same ~/.openclaw
• repeated prompts in the same Discord thread while one turn is still running
• a large/stale session store making session loading very slow
• CPU starvation/event-loop stalls on the host

Checks I’d run:

ps -ef | rg '[o]penclaw|node.*openclaw'
openclaw gateway status
openclaw sessions cleanup --dry-run

If cleanup shows a lot of stale session entries, run this only after reading the dry-run output:

[unkempt anvil]

openclaw sessions cleanup --enforce
openclaw gateway restart

Also start a fresh Discord thread/session after cleanup. If the same lock error still happens on a single gateway process with no concurrent prompts, I’d file it as a bug with this exact log. The session-resource-loader:34124ms line is important evidence. Issue tracker: https://github.com/openclaw/openclaw/issues

[wary hound]

Nope :

Maintenance mode: enforce
Entries: 54 -> 54 (remove 0)
Would prune missing transcripts: 0
Would retire stale direct DM sessions: 0
Would prune stale: 0
Would cap overflow: 0
Would prune unreferenced artifacts: 0
Planned session actions:

I don't have multiple instances running rn

[unkempt anvil]

That rules out the easy stuff. I checked current main past the latest git beta tag, and there is one new relevant-looking fix:

1b82c0e3d9 fix(followup,reply): stop model-fallback retries duplicating session entries
Closes #83404

That is not the exact same error string, but it is very close to your symptoms: fallback retries duplicating session entries, multiple answers, and transcript/session weirdness after failed candidates. It landed after v2026.5.18-beta.1, so it is definitely not in npm 2026.5.16-beta.7 / beta.6.

So current state as I see it:

• npm latest: 2026.5.12
• npm beta: 2026.5.16-beta.7
• git tag v2026.5.18-beta.1: has visible-reply fixes, but not this newer fallback/session duplication fix
• main: has the newer fallback/session duplication fix

If you want to test the fix before the next beta, the path is main/dev, not another published beta:

[unkempt anvil]

openclaw update --tag main --dry-run
openclaw update --tag main --yes
openclaw gateway restart

If you don’t want to run main, I’d stay on 2026.5.16-beta.6, disable fallbacks, and wait for the next npm beta. Given you’ve ruled out duplicate processes and session cleanup, this is now strong bug-report territory. Include both log lines:

session-resource-loader:34124ms
EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released

and mention #83404/1b82c0e3d9 may be related. Issue tracker: https://github.com/openclaw/openclaw/issues

[wary hound]

v2026.5.18 is offficially out, I'll test it, though with 2026.5.16-beta.5 it worked pretty fine

[unkempt anvil]

Good call. If 2026.5.18 still doesn’t send Discord replies via OpenRouter, the most useful next bundle is:

• openclaw --version
• which OpenRouter model/provider string you’re using
• the gateway log lines around the inbound Discord message and the model response
• whether the agent produces a final answer in the session UI but fails only on Discord delivery

That last distinction matters: if the run completes but Discord stays silent, it’s likely a delivery/channel path issue; if the run never reaches a final response, it’s more likely model/tool-calling/provider behavior.

[wary hound]

After testing it seems to work, I have the messages back and the verbose, 2026.5.18 was the fix !

Though I still have some errors and stuff but not blocking

09:33:40 [ws] ⇄ res ✓ sessions.list 171ms conn=6bda3f12…97a8 id=7bc8e91a…f701
09:33:41 [ws] ⇄ res ✗ sessions.resolve 31ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=a1a226de…4d0f id=15fb6d35…9cfe
09:33:41 [ws] ⇄ res ✗ sessions.resolve 10ms errorCode=INVALID_REQUEST errorMessage=No session found: current conn=4f87f6e6…7e15 id=826641fe…daf9
09:33:47 [diagnostic] lane task error: lane=main durationMs=13868 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/378eb2b8-4c88-42e0-bb5b-bec8287be31c-topic-1505953895808110692.jsonl"
09:33:47 [diagnostic] lane task error: lane=session:agent:main:discord:channel:1505953895808110692 durationMs=13883 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/378eb2b8-4c88-42e0-bb5b-bec8287be31c-topic-1505953895808110692.jsonl"
09:33:47 Embedded agent failed before reply: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/378eb2b8-4c88-42e0-bb5b-bec8287be31c-topic-1505953895808110692.jsonl
09:35:20 [diagnostic] lane task error: lane=main durationMs=14644 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/7353e8d7-de9e-4278-8916-25e1a35335a3-topic-1506198348871499796.jsonl"
09:35:20 [diagnostic] lane task error: lane=session:agent:main:discord:channel:1506198348871499796 durationMs=14664 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/7353e8d7-de9e-4278-8916-25e1a35335a3-topic-1506198348871499796.jsonl"
09:35:20 Embedded agent failed before reply: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/7353e8d7-de9e-4278-8916-25e1a35335a3-topic-1506198348871499796.jsonl
09:35:41 [diagnostic] lane task error: lane=main durationMs=12534 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/7353e8d7-de9e-4278-8916-25e1a35335a3-topic-1506198348871499796.jsonl"
09:35:41 [diagnostic] lane task error: lane=session:agent:main:discord:channel:1506198348871499796 durationMs=12543 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/7353e8d7-de9e-4278-8916-25e1a35335a3-topic-1506198348871499796.jsonl"
09:35:41 Embedded agent failed before reply: session file changed while embedded prompt lock was released: /home/container/.openclaw/agents/main/sessions/7353e8d7-de9e-4278-8916-25e1a35335a3-topic-1506198348871499796.jsonl
09:36:22 [sessions/store] capped session entry count
09:36:23 [ws] ⇄ res ✓ agent 144ms runId=08926990-2246-4e1e-a604-762355a06f33 conn=de5e9e4c…efd1 id=f392a6bf…cde6
09:37:29 [ws] ⇄ res ✓ agent.wait 64583ms conn=de5dbe30…dfe0 id=3d2b872e…afef
09:37:30 [ws] ⇄ res ✓ chat.history 56ms conn=b7122c1a…c815 id=3dc77d05…4a32
09:37:30 [ws] ⇄ res ✓ chat.history 133ms conn=0e451f76…3b49 id=4df298d5…46d8

[unkempt anvil]

Nice, that points pretty strongly at 2026.5.18 fixing the OpenRouter reply path.

For the remaining logs:

• sessions.resolve ... No session found: current looks like a UI/client asking for the special current session when there isn’t one in that connection context. If the dashboard still loads and real sessions work, I’d treat that as noisy/non-blocking.
• [sessions/store] capped session entry count is normal session-store pruning/noise, not a failure.
• EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released is the one I’d keep an eye on. It usually means two things tried to operate on the same session transcript file at the same time, or the same Discord thread/channel event was processed through overlapping lanes. Common causes to rule out: two gateway instances/containers running with the same Discord bot token, duplicate inbound delivery after a restart, or multiple prompts hitting the same thread while a previous embedded run is still active.

If it only happened during upgrade/restart testing and replies now work, I’d leave it alone. If it repeats during normal use on 2026.5.18, please file it with the exact version, whether there is only one gateway process/container, and a log slice like this: https://github.com/openclaw/openclaw/issues

Useful docs for the debug bundle: https://docs.openclaw.ai/start/faq and https://docs.openclaw.ai/gateway/troubleshooting

[wary hound]

I don't use the dashboard/ui only discord, is there a way to disable it ?

[unkempt anvil]

Yes, you can disable just the browser Control UI. The Gateway itself still needs to run for Discord, but the dashboard static UI can be turned off:

openclaw config set gateway.controlUi.enabled false
openclaw gateway restart

Or in openclaw.json / JSON5:

{
  gateway: {
    controlUi: { enabled: false }
  }
}

[unkempt anvil]

Docs: https://docs.openclaw.ai/web and config reference: https://docs.openclaw.ai/gateway/configuration

One nuance: if you truly have no dashboard/browser tab open, those sessions.resolve current lines may be coming from another client/tool connection rather than the Control UI. Disabling gateway.controlUi.enabled should remove the served dashboard, but it won’t disable the Gateway WebSocket/API because Discord uses the Gateway too.