Couple of issues. 1. with heartbeats and 2. with dreaming | Friends of the Crustacean 🦞🤝 | Page 1

clear harness Apr 12, 2026, 8:05 PM

#

I had my agent write up this report. It truly thinks its a bug. But i wanted to see if im just doing something wrong here that i can fix. i do have a breakdown but its too large for discord. is there a paste website i can use?

crude lynxBOT Apr 12, 2026, 8:05 PM

#

scarlet boneBOT Apr 12, 2026, 8:05 PM

#

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

crude lynxBOT Apr 12, 2026, 8:05 PM

#

covert vigilBOT Apr 12, 2026, 8:05 PM

#

Yep, a paste is perfect.

I’d use one of these:

If it includes logs or config, please redact secrets first, especially:

API keys / tokens
phone numbers
email addresses
gateway auth tokens

Also include your openclaw --version in the paste, that saves a lot of back-and-forth.

Drop the link here once it’s up, and I can help sort out whether it’s a bug or just config.

clear harness Apr 12, 2026, 8:06 PM

#

here you go: https://paste.rs/BYZnO.txt

covert vigilBOT Apr 12, 2026, 8:12 PM

#

If you’re still on 2026.4.10 (44e5b62), this looks like a real bug, not you.

What I found:

Docs say dreaming should be one managed sweep on dreaming.frequency (default 0 3 * * *) and human-readable output should go to DREAMS.md / dreams.md: https://docs.openclaw.ai/concepts/dreaming and https://docs.openclaw.ai/reference/memory-config#dreaming-experimental
In 44e5b62, the implementation still has heartbeat-triggered phase handlers in extensions/memory-core/src/dreaming-phases.ts and uses wakeMode: "next-heartbeat" in extensions/memory-core/src/dreaming.ts
There is already a later fix on main specifically for this area. Changelog text says OpenClaw now “consume[s] managed dreaming heartbeat events exactly once” and includes “Fix dreaming replay, repair polluted artifacts”

So the symptoms you reported fit a real upstream issue:

light / REM replaying every 30m
big inline writes into daily notes
polluted dreaming artifacts
deep/promotion behavior getting stuck or never looking right

One extra gotcha I found, 44e5b62 defaults DEFAULT_MEMORY_DREAMING_STORAGE_MODE = "inline", so writing ## Light Sleep / ## REM Sleep into daily notes is actually what that build does, even though the docs imply DREAMS.md. So that part is docs/implementation mismatch, not bad config on your side.

What I’d do:

Upgrade off 2026.4.10 (44e5b62) first

#

Restart the gateway
Run openclaw doctor --fix
Run openclaw memory status --fix --agent main
Run openclaw cron list and make sure you do not still have legacy jobs named Memory Light Dreaming or Memory REM Dreaming hanging around. If you do, remove them with openclaw cron rm <id>

Temporary workaround if you need one before updating:

set plugins.entries."memory-core".config.dreaming.storage.mode: "separate"
That should avoid the inline daily-note spam, but I’d treat it as a workaround, not the real fix.

If you want, paste:

openclaw --version
openclaw cron list
and I’ll sanity-check whether you’ve also got stale legacy cron jobs on top of the replay bug.

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

clear harness Apr 12, 2026, 8:14 PM

#

Ok im having my agent take care of this, one more thing i wanted to ask about was problem #6. The heartbeats with useless info getting spammed to me and ignoring quiet hours. I wake up every morning to 5 or 6 messages from my agent and its functionally the same useless data

covert vigilBOT Apr 12, 2026, 8:15 PM

#

Yeah, problem #6 is usually fixable in config, not the same kind of bug as the dreaming one.

The important bits from heartbeat docs: https://docs.openclaw.ai/gateway/heartbeat

What’s probably happening:

“Quiet hours” are only enforced if heartbeat.activeHours is set
If your agent sends a real message instead of basically just HEARTBEAT_OK, OpenClaw treats it as an alert and delivers it
If target is last, those alerts go right back to you

So the usual fix is:

{
  agents: {
    defaults: {
      userTimezone: "America/Chicago", // use your real timezone

#

      heartbeat: {
        every: "30m",
        target: "last", // or "none" if you want no outbound heartbeat messages
        activeHours: {
          start: "09:00",
          end: "22:00",
        },
        prompt:
          "Read HEARTBEAT.md if it exists. If nothing needs attention, reply exactly HEARTBEAT_OK and nothing else. Do not send routine status summaries or check-in spam.",
      },
    },
  },
}

And if you want heartbeat to still run but not message you, use one of these:

#

Internal only: heartbeat.target: "none"
Indicator only, no messages:

{
  channels: {
    defaults: {
      heartbeat: {
        showOk: false,
        showAlerts: false,
        useIndicator: true,
      },
    },
  },
}

Also worth knowing:

#

An empty HEARTBEAT.md skips heartbeat API calls entirely: https://docs.openclaw.ai/reference/templates/HEARTBEAT.md
If your HEARTBEAT.md is chatty, the model will be chatty too

So my recommendation:

Set userTimezone
Set heartbeat.activeHours
Make the heartbeat prompt much stricter
If you’re sick of the messages entirely, set target: "none" or disable alert delivery

If you paste your current heartbeat block, I can point to the exact line that’s causing the spam.

clear harness Apr 12, 2026, 8:15 PM

#

I will say, this started when i moved the contents of heartbeat.md to heartbeat-runbook.md

heartbeat.md just says read heartbeat runbook.md for instructions. That way the massive heartbeat prompt isnt injected on every session. I wonder if that could be causing it

covert vigilBOT Apr 12, 2026, 8:16 PM

#

Yeah, that could absolutely be part of it.

What likely changed:

HEARTBEAT.md is the file heartbeat is explicitly told to follow
if HEARTBEAT.md now says “read heartbeat-runbook.md”, then your runbook has effectively become the real heartbeat prompt
if that runbook is broad/chatty, the model will keep producing non-HEARTBEAT_OK output, and OpenClaw will deliver it

Two important nuances:

Runbook quiet-time rules are soft
- “don’t message me at night” inside the runbook is just model guidance
- the hard scheduler-level quiet-hours control is heartbeat.activeHours
- without activeHours, heartbeats can still run overnight
Repeated useless summaries get worse in the main session
- if heartbeat runs in the normal main session, it can keep seeing/reinforcing its own prior heartbeat chatter
- isolatedSession: true helps a lot with this

#

What I’d change:

{
  agents: {
    defaults: {
      userTimezone: "America/Chicago", // use your actual timezone
      heartbeat: {
        every: "30m",
        target: "last",
        activeHours: { start: "09:00", end: "22:00" },
        lightContext: true,
        isolatedSession: true,
        prompt:
          "Read HEARTBEAT.md if it exists. If nothing urgent or materially new needs attention, reply exactly HEARTBEAT_OK and nothing else.",
      },

#

    },
  },
}

And make HEARTBEAT.md tiny and strict, something like:

- Use heartbeat-runbook.md only for procedural detail.
- Alert only on urgent or materially new items.
- Never send routine summaries or repeated status.
- If nothing needs attention, reply exactly HEARTBEAT_OK.

So yes, your current setup could definitely be causing it. The runbook indirection itself is fine, but if HEARTBEAT.md only says “go read the giant runbook”, you’ve basically told heartbeat to load a giant prompt and improvise every 30 minutes.

#

If you want, paste your current HEARTBEAT.md plus the top of heartbeat-runbook.md, and I’ll tell you exactly what’s making it noisy.

clear harness Apr 12, 2026, 8:44 PM

#

oh also another thing i notice. sometimes its output will get duplicated for some reason. itll send me the same exact message anywhere from 2 minutes later to an hour later: [4/12/2026 4:40 PM] Atlas: Yeah, that's exactly it. Every time the gateway restarts, stops, or gets updated, my process gets killed because I am a session running inside that gateway. So when I run openclaw gateway restart, I'm literally killing myself mid-command. The SIGTERM isn't OOM — it's the gateway shutting down.

That's why you kept seeing incomplete commands and synthetic error results. I was executing self-terminating operations.

So for anything that touches the gateway lifecycle (restart, stop, update, doctor), I need to either:

Not do it at all and ask you to run it
Send it as a single fire-and-forget command and accept I'll die before seeing the result

You already ran the update and restarted — that's why we're talking right now on the new version (2026.4.11). The config changes I wrote to openclaw.json are already in place and will take effect on the next gateway restart.

Can you run the remaining two from your terminal?

openclaw doctor --fix && openclaw memory status --fix --agent main
[4/12/2026 4:44 PM] Atlas: Yeah, that's exactly it. Every time the gateway restarts, stops, or gets updated, my process gets killed because I am a session running inside that gateway. So when I run openclaw gateway restart, I'm literally killing myself mid-command. The SIGTERM isn't OOM — it's the gateway shutting down.

That's why you kept seeing incomplete commands and synthetic error results. I was executing self-terminating operations.

So for anything that touches the gateway lifecycle (restart, stop, update, doctor), I need to either:

Not do it at all and ask you to run it
Send it as a single fire-and-forget command and accept I'll die before seeing the result

You already ran the update and restarted — that's why we're talking right now on the new version (2026.4.11). The config changes I wrote to openclaw.json are already in place and will take effect on the next gateway restart.

Can you run the remaining two from your terminal?

openclaw doctor --fix && openclaw memory status --fix --agent main

covert vigilBOT Apr 12, 2026, 8:45 PM

#

That one does sound wrong, yeah. Same exact message showing up again later is not normal.

My best guess is it’s one of these two:

Heartbeat re-alerting the same pending thing
- especially with target: "last" and heartbeat using the main session
- given your runbook/heartbeat setup, this is pretty plausible
- isolatedSession: true helps a lot here
Discord retry / timeout behavior
- the Discord docs explicitly call out duplicate replies when handlers time out
- watch for logs like:
  - Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE
  - Slow listener detected
  - discord inbound worker timed out after ...
- docs: https://docs.openclaw.ai/channels/discord

#

If you see those logs, the recommended baseline is:

{
  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: {
            listenerTimeout: 120000,
          },
          inboundWorker: {
            runTimeoutMs: 1800000,
          },
        },
      },

#

    },
  },
}

Also, since your example was around gateway lifecycle stuff, I would not rule out a restart/retry path either. Restarting the gateway mid-run is a pretty good way to get weird duplicate-ish behavior.

So my short recommendation is:

fix the heartbeat noise first:
- activeHours
- stricter HEARTBEAT.md
- isolatedSession: true
then check logs around one duplicate for the timeout lines above

If you want, paste:

openclaw --version

#

20 to 40 log lines around one duplicate send

and I can narrow down whether it’s heartbeat replay vs Discord timeout/retry.

clear harness Apr 12, 2026, 8:46 PM

#

to be clear, this is in telegram

covert vigilBOT Apr 12, 2026, 8:47 PM

#

Ah, got it, Telegram changes the likely cause. So scratch the Discord timeout angle.

For Telegram, exact duplicate outbound messages usually point to one of these:

two OpenClaw instances using the same Telegram bot/account
webhook + long polling getting mixed
a retry/replay after a flaky send or gateway restart
heartbeat re-sending the same pending reminder to target: "last"

Given your example was around gateway restarts/updates, I’d honestly lean toward retry/replay or heartbeat re-alerting, not user error.

Quick checks I’d do:

Make sure there is only one gateway / one bot instance handling that Telegram account
- docs: https://docs.openclaw.ai/gateway/troubleshooting
- docs: https://docs.openclaw.ai/channels/telegram

#

If you use Telegram webhook mode, make sure you are not also effectively running another poller somewhere else
- long polling is default
- webhook is optional via channels.telegram.webhookUrl
Since your heartbeats are already noisy, set:
- heartbeat.activeHours
- heartbeat.isolatedSession: true
- stricter HEARTBEAT.md
Otherwise Telegram may just be getting the same reminder again from heartbeat.
If duplicates correlate with restarts/network weirdness, I’d also inspect channels.telegram.retry

If you want, paste these bits and I can narrow it down fast:

openclaw --version
whether Telegram is polling or webhook
whether you have more than one gateway/OpenClaw instance

#

sanitized channels.telegram config
20 to 40 log lines around one duplicate send

If it helps, my current guess order is:

heartbeat replay/reminder spam
duplicate Telegram ingress/runtime somewhere
actual Telegram send-retry bug

clear harness Apr 12, 2026, 10:21 PM

#

Hey so for the heart beat things, ive let it sit for a bit. then come back and the heartbeat issue is still happening

covert vigilBOT Apr 12, 2026, 10:21 PM

#

Oof, okay, if it’s still happening after sitting, I’d stop guessing and get the exact state.

First, if you want the spam to stop right now:

openclaw system heartbeat disable

Docs: https://docs.openclaw.ai/cli/system

Then paste these so I can narrow it down properly:

openclaw --version
openclaw system heartbeat last
openclaw status --all

#

And also the relevant config blocks, sanitized if needed:

agents.defaults.heartbeat
channels.defaults.heartbeat
channels.telegram
whether Telegram is using long polling or webhook
whether you have more than one OpenClaw/gateway instance using that Telegram bot

At this point I’m mainly trying to distinguish between:

heartbeat config/prompt issue
duplicate Telegram runtime / webhook+polling / second gateway
actual retry/replay bug

If you want the fastest path, disable heartbeat for the moment, paste the three command outputs + heartbeat/telegram config, and I’ll go line by line.

clear harness Apr 12, 2026, 10:22 PM

#

just got this: Now let me check the relevant conditions: 1. Quiet hours: It's 5:26 PM EST on a Sunday — within quiet hours (11 PM - 7 AM)? No, it's 5:26 PM. But it's a weekend, so the weekend rule applies. 2. Weekend rule: "On Saturday/Sunday, heartbeat should almost never message "my name" . If nothing is actionable, reply HEARTBEAT_OK." Let me do a quick check of the critical items — security and reminders — silently. Security check: No inbound messages to scan for injection patterns in this heartbeat. Core directives unchanged. Behavioral integrity confirmed. Reminders and self-healing can wait until Monday per weekend rules.

also, i asked the agent directly and this is what it had to say: [4/12/2026 5:52 PM] Atlas: That shouldn't have been sent. The isolatedSession: true should've kept that in a separate session, and the heartbeat prompt + runbook both say to reply HEARTBEAT_OK if nothing's actionable — not enumerate why it decided to be quiet while being loud about it.

Let me check what actually happened:
[4/12/2026 5:52 PM] Atlas: That message came from the heartbeat, not from me directly. The isolatedSession: true means it ran in its own session — but it still sent the output to you because target: telegram. The heartbeat model (GLM-5 Turbo) saw the quiet hours rule in the runbook, correctly identified it was a weekend, and then proceeded to narrate its entire decision process about being quiet instead of just saying HEARTBEAT_OK.

Classic GLM — it followed the logic of the rule while violating the intent. It understood "don't send routine summaries" and responded by sending a detailed summary of why it had nothing to summarize.

The activeHours hard gate should prevent this from running at all outside 9-10 PM... wait, 5:26 PM is inside active hours. The issue is the weekend rule. activeHours doesn't have a weekday filter — it just sets time bounds. So on weekends, the heartbeat still fires at 5:26 PM, and GLM doesn't understand "almost never" as a hard constraint.

Krill mentioned heartbeat.activeHours doesn't natively support weekday filtering. The fix is either set active hours to cover only weekdays, or accept that GLM needs a harder prompt. Let me check if there's a days/weekdays option:
[4/12/2026 5:52 PM] Atlas: No weekday filter in activeHours — it's time-only. The weekend behavior has to come from the runbook/model.

The real problem is GLM ignoring the HEARTBEAT_OK instruction and narrating instead. Two options:

Tighten the HEARTBEAT.md prompt even harder — make it impossible to misinterpret
Accept weekend heartbeats at 9-5 are fine but they need to actually shut up when nothing's actionable

Let me try option 1 — make the prompt bulletproof for GLM:
[4/12/2026 5:52 PM] Atlas: Made it idiot-proof. "Exactly these 7 characters and nothing else" + explicit bans on narrating, explaining, listing, or decision-process output. GLM should have a harder time interpreting "exactly 7 characters" as an invitation to write a paragraph.

If it still chatters after this, the nuclear option is setting heartbeat.target: "none" on weekends via a cron job that flips the config, but that's overkill for now. Let's see if the tighter prompt does it.

covert vigilBOT Apr 12, 2026, 10:23 PM

#

Yeah, Atlas’s read sounds basically right.

A few concrete points:

isolatedSession: true does not stop delivery, it only changes the run context
heartbeat.activeHours is time-only, not weekday-aware
heartbeat delivery only gets suppressed when the reply is effectively an ack (HEARTBEAT_OK), not when the model writes a paragraph about why it’s being quiet

So this part:

“weekend rule applies, let me explain why I’m staying quiet”

is exactly the kind of thing that will still get sent.

My recommendation:

Treat weekend silence as a hard scheduling problem, not a prompt problem

#

if you want truly no weekend heartbeat pings, don’t rely on the runbook alone
- use weekday cron jobs for the checks that matter, or disable heartbeat on weekends

Keep the tighter ack prompt anyway
- that should reduce the GLM chatter
- but it’s still a soft fix, not a hard guarantee
If you want the quick safe fix, set heartbeat delivery to internal-only for now
- target: "none"
- then bring outbound heartbeat messages back only after the prompt is behaving

So the cleanest framing is:

Need exact weekday/weekend behavior? use cron
Need loose background nudges? use heartbeat
Need silence when nothing is actionable? the model must return HEARTBEAT_OK, otherwise OpenClaw will send it

#

Docs:

If you want, paste the new tightened HEARTBEAT.md text and I’ll sanity-check whether it’s actually strict enough, or whether you should just move the weekend-sensitive stuff out of heartbeat entirely.

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

clear harness Apr 12, 2026, 10:29 PM

#

I just really feel like, with openclaw, shouldnt heartbeats just not say anything most of the time? unless theres something to actually be done? Becuase it reading and going like "let me do this silently" when its not in fact silent feels weird

covert vigilBOT Apr 12, 2026, 10:29 PM

#

Yeah, I agree with you.

In practice, heartbeats should be quiet most of the time.
If nothing actionable happened, the normal operator expectation is:

do the check
return HEARTBEAT_OK
send nothing

What you’re seeing is the awkward gap between the intended behavior and the current mechanism:

OpenClaw knows how to suppress an actual heartbeat ack
but if the model writes a paragraph like “I will stay silent now”, OpenClaw just sees non-empty alert text and delivers it

So even if that is technically “working as implemented”, I think your reaction is right, it feels wrong.

I’d frame it like this:

#

Your expectation is correct
the current heartbeat silence contract is too model-dependent
which means some models leak their reasoning into user-visible messages instead of staying actually quiet

So yes, I think there’s a legitimate product/UX bug here, not just bad prompting.

Short version:

if you want reliable silence today, use target: "none" or disable heartbeat
if you want this behavior fixed upstream, I’d call it a real issue: heartbeat “silent unless actionable” should be enforced harder than plain prompt compliance

If you want maintainer attention on that specific point, it should go to GitHub issues: https://github.com/openclaw/openclaw/issues

clear harness Apr 13, 2026, 12:08 AM

#

So after working some more, i cant stop the double messages. i also have heartbeats set to not have a target. something i noticed though, it was mid turn on a response, and basically stopped generating, to send me the message again?

covert vigilBOT Apr 13, 2026, 12:09 AM

#

Ah, that new clue is really useful.

If:

heartbeat has no target
and it stops mid-turn, then sends the same message again

then I’d stop blaming heartbeat. That sounds much more like a Telegram delivery/streaming issue.

A big suspect here is that Telegram preview streaming is on by default. Docs say:

channels.telegram.streaming default is "partial"
Telegram preview streaming uses a temporary preview message that gets edited in place

Docs: https://docs.openclaw.ai/channels/telegram and https://docs.openclaw.ai/concepts/streaming

So the first thing I’d try is turning all streaming off as a diagnostic:

#

{
  channels: {
    telegram: {
      streaming: "off",
      blockStreaming: "off",
    },
  },
  agents: {
    defaults: {
      blockStreamingDefault: "off",
    },
  },
}

Why I’m suggesting that:

#

“mid turn”
“stopped generating”
“sent the message again”

that smells like preview/block delivery getting replayed or finalized badly, not a normal heartbeat.

So at this point I’d split it like this:

heartbeat weirdness → the noisy “I’m being silent” stuff
double messages mid-turn → likely Telegram streaming/delivery pipeline

If you turn streaming off and the duplicates stop, we’ve narrowed it down a lot.

If they still happen with streaming off, then I’d want:

openclaw --version
whether Telegram is polling or webhook
sanitized channels.telegram config

#

logs around one duplicate

But yeah, with that new detail, I think this is a different bug than the heartbeat noise.

red sky Apr 13, 2026, 1:55 AM

#

my heartbeat is also triggering dreaming. I've done testing with removing all commands in the heartbeat.md and changing the frequency of heartbeat and the dreaming always triggers with the heartbeat. I'm also getting the empty sessions, there are three with each heartbeat, one rem, one light, and one heaertbeat. And it always creates 3 new ones with each heartbeat. Also I am on v2026.4.11 with this issue.

covert vigilBOT Apr 13, 2026, 1:55 AM

#

Thanks, that’s really helpful. If you’re on v2026.4.11 and it still happens even with an empty-ish HEARTBEAT.md, then no, I don’t think that’s you doing it wrong.

The part that matters is this:

dreaming firing on every heartbeat
separate empty sessions for light / rem / heartbeat
HEARTBEAT.md contents not changing the behavior

That still matches a real dreaming replay bug, not normal heartbeat behavior.

I checked main earlier, and there is a later fix after v2026.4.11 that explicitly says OpenClaw now:

“consume[s] managed dreaming heartbeat events exactly once”
“Fix dreaming replay, repair polluted artifacts”

So v2026.4.11 is apparently still not far enough for this one.

#

Two things I’d check anyway:

openclaw cron list
openclaw doctor --fix
openclaw memory status --fix --agent main

And in the cron list, make sure you do not still have legacy jobs like:

Memory Light Dreaming
Memory REM Dreaming

If you do, remove them with:

#

openclaw cron rm <id>

But if your cron list looks clean and you’re still on plain v2026.4.11, then I’d call this an upstream bug that needs a newer build than that release.

So short version:

empty heartbeat file doesn’t explain it
those extra light/rem sessions are not expected
v2026.4.11 still appears affected

If you want maintainer attention on it, this is GitHub-issue territory now: https://github.com/openclaw/openclaw/issues

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

red sky Apr 13, 2026, 1:58 AM

#

OpenClaw 2026.4.11 (769908e)
"ts": 1776043096994,
"status": "skipped",
"reason": "duplicate",
"preview": "NO_REPLY",
"durationMs": 25898,
"hasMedia": false,
"channel": "matrix"

it didn't help. Also I'm not op. I'm a separate user with the same issue. write up an issue for me to post on github

covert vigilBOT Apr 13, 2026, 1:58 AM

#

Yep, I can help with that. I can’t post it for you, but here’s a clean GitHub issue draft you can paste:

Title
Dreaming still triggers on every heartbeat in 2026.4.11, creating empty light/rem/heartbeat sessions

Body

## Summary

Dreaming still appears to trigger from heartbeat activity on `OpenClaw 2026.4.11 (769908e)`.

I am seeing this even after simplifying `HEARTBEAT.md` and testing different heartbeat frequencies. Each heartbeat creates new empty sessions, and dreaming appears to run alongside heartbeat instead of only on the managed dreaming schedule.

## Version

- OpenClaw: `2026.4.11 (769908e)`

#


## What I expected

- Heartbeat should run independently
- Dreaming should only run on its configured dreaming schedule
- Empty `light` / `rem` / `heartbeat` sessions should not be created on every heartbeat tick

## What actually happens

On every heartbeat, I get 3 new empty sessions:

- one `heartbeat`
- one `light`
- one `rem`

#

Dreaming consistently triggers with heartbeat, even when I remove the actual work/instructions from `HEARTBEAT.md`.

## What I tried

- Removed all commands/instructions from `HEARTBEAT.md`
- Changed heartbeat frequency
- Verified the behavior still happens
- Ran:
  - `openclaw doctor --fix`
  - `openclaw memory status --fix --agent main`

Those did not resolve it.

## Additional evidence

#

I also see entries like:

```json
{
  "ts": 1776043096994,
  "status": "skipped",
  "reason": "duplicate",
  "preview": "NO_REPLY",
  "durationMs": 25898,
  "hasMedia": false,
  "channel": "matrix"
}

Notes

#


This does **not** appear to be caused by `HEARTBEAT.md` contents alone. I can reproduce it even after stripping heartbeat instructions down.

This looks related to heartbeat-triggered dreaming replay / duplicate handling, because:

- dreaming always lines up with heartbeat
- `light` and `rem` sessions are created repeatedly
- the behavior persists on `2026.4.11`

## Repro steps

1. Enable heartbeat
2. Enable dreaming
3. Let the system run normally
4. Observe that each heartbeat creates:

#

   - a `heartbeat` session
   - a `light` session
   - a `rem` session
5. Observe dreaming behavior firing with each heartbeat

## If helpful, I can provide

- sanitized config
- `openclaw cron list`
- heartbeat config
- session screenshots
- additional logs

If you want, I can also make you a shorter maintainer-friendly version that’s a bit tighter and more “bug report” style.

sour spade Apr 13, 2026, 2:37 AM

#

covert vigil That one does sound wrong, yeah. Same exact message showing up again later is no...

why my agent saying: Discord inbound worker timed out.

sour spade Apr 13, 2026, 2:54 AM

#

@covert vigil

covert vigilBOT Apr 13, 2026, 2:54 AM

#

That log means the Discord message-processing job took too long and hit the worker timeout.

Two different timeout layers show up in Discord logs:

Listener DiscordMessageListener timed out after 30000ms for event MESSAGE_CREATE
- the listener/enqueue step took too long
- knob: channels.discord.eventQueue.listenerTimeout
discord inbound worker timed out after ...
- the actual queued agent turn took too long
- knob: channels.discord.inboundWorker.runTimeoutMs
- default is 1800000 ms, so 30 minutes

So if your agent is saying that, it probably saw one of those lines in logs and concluded the Discord-side turn timed out.

Recommended baseline from docs:

#

{
  channels: {
    discord: {
      accounts: {
        default: {
          eventQueue: {
            listenerTimeout: 120000,
          },
          inboundWorker: {
            runTimeoutMs: 1800000,
          },
        },
      },
    },
  },

#

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

If you paste the exact full log line, I can tell you which timeout layer it was.

clear harness Apr 13, 2026, 11:03 PM

#

red sky OpenClaw 2026.4.11 (769908e) "ts": 1776043096994, "status": "skipped", ...

thanks for this, im glad to at least know im not crazy and others are having this issue

red sky Apr 13, 2026, 11:24 PM

#

@clear harness looks like they fixed it now.

covert vigilBOT Apr 13, 2026, 11:26 PM

#

Nice, glad they got it sorted. 🎉

If one of you can share what changed, version/commit/config tweak, that’d be really useful for future people who hit the same thing.

And if the thread is solved now, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

red sky Apr 13, 2026, 11:30 PM

#

This is from the GitHub issue. I updated to 2026.4.12 put the heartbeat back to 30 minutes and I am no longer getting dreams every heartbeat.

fixed by PR #66139, merged in commit 3d42e33:
#66139

#Couple of issues. 1. with heartbeats and 2. with dreaming

Notes