openclaw - 💡(How to fix) Fix Control UI hides older cron-backed chat sessions after upgrade because chat session fetch is limited to activeMinutes:120

Summary

After upgrading OpenClaw via the web interface, a cron-backed chat session disappeared from the Control UI chat/session selector even though the cron job, session data, and session index were all still present and healthy.

In my case, the missing session was a stable cron session for daily-planning.

Version / environment

• OpenClaw version: 2026.5.18
• OS: macOS
• Install style: global/local runtime install, using the shipped Control UI bundle
• Upgrade path: upgraded from the web interface

Expected behavior

Cron-backed sessions that still exist and are valid should remain discoverable/selectable in the chat UI, even if they have not been updated in the last 120 minutes.

Actual behavior

The Control UI chat/session selector only showed more recently updated sessions. Older cron-backed sessions disappeared from the selector, even though they still existed and were available through the backend.

In my case:

• daily-review was visible because it had a recent update
• daily-planning was missing because its last update was roughly 3 hours old

What I verified

This did not appear to be a cron or backend data problem.

I verified that the missing session still existed in all of the following places:

• cron job definition
• cron runtime state
• persisted session transcripts
• session index
• live session listing from CLI

The backend/session store still knew about the session correctly.

Root cause

The issue appears to be in the Control UI bundle, not the backend.

In the installed Control UI bundle, multiple chat-related session refresh paths use a hard-coded filter:

activeMinutes:120

Examples include chat-side session refreshes such as:

• initial/refresh chat session loading
• new chat/session creation flows
• session-switch refresh flows
• session.message-triggered refresh flows

Because of that 120-minute cutoff, older-but-still-valid cron sessions are excluded from the chat UI session list.

Temporary workaround

I locally patched the installed Control UI bundle to widen the session lookback window, replacing:

activeMinutes:120

with:

activeMinutes:525600

After that change, the missing cron session became eligible to appear in the chat/session selector again.

Why this seems like a bug

The session was not deleted, invalid, or broken. It was simply older than the UI's hard-coded recent-session window.

That makes stable cron-backed sessions effectively disappear from the chat UI unless they happen to have run recently, which seems too aggressive for long-lived assistant workflows.

Suggested fix

A few possible fixes:

1. Stop filtering chat session discovery so aggressively in the Control UI.
2. Use a much larger default lookback window for chat session lists.
3. Treat cron-backed sessions specially so they remain discoverable even when older.
4. Make the recent-session window configurable instead of hard-coded.

Notes

I also hit a separate upgrade issue beforehand where the upgraded Control UI and a stale long-running gateway process had a protocol mismatch. Restarting the gateway fixed that part. The missing cron session problem remained after the protocol mismatch was resolved, and appears to be a separate UI regression.