Summary

Channel sessions (e.g. Discord channel sessions like agent:main:discord:channel:<id>) are never reset by the built-in session.reset.mode=daily policy, even when the session is clearly stale.

Environment

• OpenClaw version: OpenClaw 2026.4.8 (9ece252)
• Node: v22.22.2
• OS: Linux 6.8.0-107-generic

Expected Behavior

A channel session with session.reset.mode=daily and atHour=10 should be reset when the first non-system-event message arrives after 10:00 UTC, provided the session's updatedAt is before the daily reset boundary.

Actual Behavior

The session is never reset. A morpheus channel session accumulated 58,000+ entries over 4 days (Apr 6–9), growing to 147 MB, despite:

• session.reset.mode=daily with atHour=10 (UTC)
• session.reset.idleMinutes=360
• The session being idle for 17+ hours overnight (last entry Apr 8 18:56 UTC, next entry Apr 9 12:22 UTC)
• The daily reset window at 10:00 UTC falling squarely in the idle period

The evaluateSessionFreshness function in reset-ClbjyzZk.js has the correct logic:

const staleDaily = dailyResetAt != null && params.updatedAt < dailyResetAt;
const staleIdle = idleExpiresAt != null && params.now > idleExpiresAt;
return { fresh: !(staleDaily || staleIdle) };

And the reply handler (reply-DW8PLbAC.js) correctly skips freshness evaluation for system events (heartbeats, cron-events) so they don't interfere.

However, the session was never reset despite meeting both staleDaily and staleIdle conditions.

Possible Causes

1. Gateway restart bumping updatedAt: A gateway restart at 07:10 UTC may have updated the session's updatedAt in sessions.json during re-initialization, making it appear fresh at the 10:00 UTC reset boundary.

2. resolveSessionResetType returning 'group' for channel sessions: Channel sessions include :channel: in their key, which triggers GROUP_SESSION_MARKERS detection. If there's a resetByType.group override (or lack thereof), the policy might differ from the default.

3. resetByChannel key mismatch: The resolveChannelResetConfig function normalizes the channel identifier, but the key format expected in resetByChannel config may not match what's passed during reply handling.

Workaround

Using a dedicated cron job to send session:reset targeting the specific session key at the desired reset hour.

Impact

Without functioning daily resets, channel session files grow unbounded, eventually causing OOM crashes on gateway restart when the large session file is loaded into memory.