OpenClaw’s newest channel bugs are about where replies land, what stays silent, and what survives restarts
Fresh OpenClaw issues and PRs show another practical delivery-boundary cluster for always-on agents. Issue #81413 reports that Google Chat group messages can collapse into the main session key, causing replies to go to the user's most recently active channel, such as WhatsApp, instead of the originating Google Chat group. Issue #81411 says cron-generated Telegram messages can render Markdown links as literal raw HTML, while long-running cron jobs still need better completion and delivery semantics. Issue #81412 and PR #81420 cover the quiet-reply edge: when a model surrounds `NO_REPLY` with explanatory text or thinking blocks, the current exact-match behavior can strip only the token or miss the suppression path, letting unwanted text or reasoning appear in chats. Two nearby PRs matter for operators too: #81418 adds a parent-PID watchdog so orphan MCP channel-server workers do not survive a killed gateway and break the next upgrade handshake, and #81417 makes memory flush thresholds scale with large model context windows so long sessions do not hit compaction with nothing persisted.
Channel agents are judged by last-mile correctness. A strong model is not useful if a Google Chat answer lands in WhatsApp, a quiet cron job posts its reasoning, a link turns into raw HTML, or an old MCP worker keeps a stale protocol alive after upgrade. These are small-looking bugs with high trust cost because users experience them as the agent speaking in the wrong place or at the wrong time.
- Issue #81413 describes Google Chat group session keys not being created and replies routing to WhatsApp through the main session key
- Issue #81411 reports cron Telegram delivery rendering Markdown links as literal raw HTML while direct message send renders correctly
- Issue #81412 explains that NO_REPLY exact-match handling still delivers surrounding text; PR #81420 strips thinking blocks before quiet-reply detection
- PR #81418 adds a parent-PID watchdog to prevent orphan MCP STDIO channel-server workers after gateway death or OOM kills
- PR #81417 replaces a hard-coded 4,000-token memory flush soft threshold with a context-window-aware default for large-window models
- Most fixes are still PRs or open issues and may not be present in the installed release
- Suppressing any message containing NO_REPLY can hide legitimate explanatory text unless scoped per job or channel
- Multi-channel routing bugs require real channel identities to reproduce; synthetic CLI tests can miss them