openclaw - ✅(Solved) Fix [Bug]: WebChat session selector shows main session as “heartbeat” after a while, making /new feel like sessions disappear [3 pull requests, 2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#66533Fetched 2026-04-15 06:25:48
View on GitHub
Comments
2
Participants
3
Timeline
11
Reactions
0
Timeline (top)
cross-referenced ×3commented ×2labeled ×2referenced ×2

In Control UI / WebChat, the session dropdown becomes confusing over time. After creating a new chat with /new or /reset, things look fine briefly, but later the selector seems to fall back to “heartbeat”, and it looks like the previous chat session disappeared.

After inspecting the backend, this does not appear to be real session loss or store corruption. The active session remains the main direct session, but the UI seems to derive the session preview/title from the latest transcript message, and heartbeat-related transcript content can take over that preview.

Root Cause

This is mainly a UX issue, but it is pretty misleading because it looks like sessions are being lost, when really the selector is being polluted by heartbeat-related preview text.

Fix Action

Fixed

PR fix notes

PR #66544: fix(gateway): exclude heartbeat sender ID from session display name

Description (problem / solution / changelog)

Summary

  • Filters out the internal "heartbeat" placeholder from the session display name fallback chain in buildGatewaySessionRow
  • Without this filter, the heartbeat delivery path's fallback sender ID ("heartbeat") flows into origin.label, which then becomes the session dropdown label in webchat

Root Cause

resolveHeartbeatSenderId (in targets.ts) returns "heartbeat" as a fallback when no real sender can be resolved. This ends up in the session entry's origin.label. When buildGatewaySessionRow computes displayName, it falls through entry.displayName -> groupName -> entry.label -> originLabel, and if all the earlier values are undefined, "heartbeat" becomes the visible session label in the webchat dropdown.

Fix

2-line change: check if origin.label is "heartbeat" before using it as originLabel in the display name fallback chain.

Closes #66533

Changed files

  • src/gateway/session-utils.ts (modified, +3/-1)

PR #66575: fix(webchat): filter heartbeat content from session selector labels

Description (problem / solution / changelog)

Fixes #66533

The WebChat session selector was showing 'heartbeat' instead of meaningful session names because session display labels are derived from the first user message in transcript files, and heartbeat messages can pollute this extraction.

Root Cause

In , the extraction logic reads transcript content without filtering heartbeat tokens (), causing heartbeat messages to become session labels in the UI dropdown.

Changes

  • Import from
  • Add heartbeat filtering when extracting first user message for labels
  • Skip messages that are pure heartbeat content ()
  • Continue to next message if heartbeat filter removes all content
  • Preserve meaningful content that mentions heartbeat contextually

Impact

Session selectors now show meaningful conversation topics instead of 'heartbeat', fixing the UX issue where sessions appeared to disappear.

Testing

✅ Follows existing heartbeat filtering patterns in codebase ✅ Handles pure heartbeat messages, mixed content, and normal messages ✅ Graceful fallback when no non-heartbeat content exists ✅ No breaking changes to session cost/usage calculation logic

Changed files

  • extensions/telegram/src/bot-message-context.audio-transcript.test.ts (modified, +22/-0)
  • extensions/telegram/src/bot-message-context.body.ts (modified, +1/-1)
  • extensions/telegram/src/bot-message-context.session.ts (modified, +2/-2)
  • src/agents/bash-tools.exec-approval-followup.test.ts (modified, +19/-0)
  • src/agents/bash-tools.exec-approval-followup.ts (modified, +7/-3)
  • src/agents/pi-embedded-subscribe.handlers.lifecycle.ts (modified, +6/-0)
  • src/auto-reply/reply/reply-payloads-base.ts (modified, +1/-4)
  • src/auto-reply/reply/reply-plumbing.test.ts (modified, +14/-0)
  • src/commands/message.test.ts (modified, +47/-0)
  • src/commands/message.ts (modified, +21/-10)
  • src/infra/session-cost-usage.heartbeat-filtering.test.ts (added, +1/-0)
  • src/infra/session-cost-usage.ts (modified, +17/-4)
  • ui/src/styles/components.css (modified, +7/-0)

PR #66656: fix(gateway): skip heartbeat diagnostics in session preview

Description (problem / solution / changelog)

## Summary

Session selectors (notably Control UI / WebChat) can become misleading over time because the backend derives lastMessagePreview from transcript tail lines, and heartbeat diagnostic entries may become the most recent content.

This change skips type: "diagnostic.heartbeat" entries when scanning for the last user/assistant preview.

Fixes #66533.

Test plan

  • pnpm exec vitest run src/gateway/session-utils.fs.test.ts

Changed files

  • src/gateway/session-utils.fs.test.ts (modified, +16/-0)
  • src/gateway/session-utils.fs.ts (modified, +5/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

In Control UI / WebChat, the session dropdown becomes confusing over time. After creating a new chat with /new or /reset, things look fine briefly, but later the selector seems to fall back to “heartbeat”, and it looks like the previous chat session disappeared.

After inspecting the backend, this does not appear to be real session loss or store corruption. The active session remains the main direct session, but the UI seems to derive the session preview/title from the latest transcript message, and heartbeat-related transcript content can take over that preview.

Steps to reproduce

  1. In the WebChat / Control UI session dropdown, I mostly see “heartbeat”
  2. If I create a new session with /new, it works briefly
  3. After a while, the selector appears to revert back to “heartbeat”
  4. This makes it feel like the new session disappeared

Expected behavior

  • /new should feel like a clearly separate fresh conversation in the UI, or
  • at minimum, the main session should not be relabeled in a misleading way by heartbeat transcript content

Actual behavior

What I verified

Backend session store is healthy sessions.json contains a valid active main session Reset archives are being created correctly on disk There is no evidence of session corruption or failed session creation The issue appears to be UI/session-preview behavior, not session persistence Relevant findings

WebChat attaches to the agent’s main session by default /new and /reset create a new transcript for the same main session key rather than a list of independent chat threads in the selector The UI/session metadata appears to derive title or preview from transcript content Heartbeat filtering seems to special-case HEARTBEAT_OK, but visible non-ack heartbeat text may still become the session preview

OpenClaw version

2026.4.12

Operating system

Ubuntu 24.04

Install method

docker

Model

openai 5.4 codex

Provider / routing chain

webchat / Control UI

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

This is mainly a UX issue, but it is pretty misleading because it looks like sessions are being lost, when really the selector is being polluted by heartbeat-related preview text.

Additional information

Possible areas to check:

session dropdown preview/title derivation in WebChat / Control UI exclude heartbeat-origin messages from session preview/title generation make /new semantics clearer in WebChat when using the main session model optionally distinguish “main session reset” from “new visible chat thread”

extent analysis

TL;DR

The issue can be addressed by modifying the session preview/title derivation in WebChat / Control UI to exclude heartbeat-origin messages.

Guidance

  • Investigate the session dropdown preview/title derivation logic in WebChat / Control UI to understand how it currently uses transcript content.
  • Consider filtering out heartbeat-related messages from the session preview/title generation to prevent them from overwriting the actual session title.
  • Review the semantics of /new in WebChat when using the main session model to determine if it can be made clearer that a new conversation is being started without creating a new session.
  • Explore the possibility of distinguishing between "main session reset" and "new visible chat thread" to improve the user experience.

Example

No code snippet is provided as the issue does not contain sufficient technical details to generate a specific example.

Notes

The provided information suggests that the issue is related to the UI/session metadata derivation and not a problem with session persistence. The solution may involve modifying the WebChat / Control UI code to handle heartbeat messages differently.

Recommendation

Apply a workaround by modifying the session preview/title derivation logic to exclude heartbeat-origin messages, as this is likely to address the UX issue without requiring significant changes to the underlying session management.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

  • /new should feel like a clearly separate fresh conversation in the UI, or
  • at minimum, the main session should not be relabeled in a misleading way by heartbeat transcript content

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING