Summary

session.reset.idleMinutes is configured but idle reset never fires. The session persists across gaps well exceeding the configured idle timeout.

Config

"session": {
  "reset": {
    "mode": "daily",
    "atHour": 4,
    "idleMinutes": 60
  }
}

Expected behavior

When a new inbound message arrives after >60 minutes of inactivity, the gateway should evaluate the session as stale and mint a new session ID.

Actual behavior

The same session ID persists all day. I observed gaps of 116 min, 110 min, and 75 min within a single day — all well beyond the 60-minute idle threshold — but the session was never reset. Only the daily 4 AM reset works.

Root cause (from reading the source)

The issue is in the iMessage inbound handler (and likely WhatsApp/other connectors too). The call order is:

1. recordInboundSession() is awaited — this calls updateLastRoute(), which sets updatedAt = Math.max(existing.updatedAt, Date.now())
2. dispatchInboundMessage() runs — this calls initSessionState() → evaluateSessionFreshness()

By the time step 2 reads the session entry, updatedAt has already been bumped to Date.now() by step 1. The idle check becomes now > now + idleMinutes * 60000 which is always false, so the session always appears fresh.

Relevant code path (minified names from dist):

• reply-DpTyb3Hh.js ~line 26424: await recordInboundSession(...) runs first
• sandbox-CRRd7UQ-.js ~line 2500: updateLastRoute() sets updatedAt: Math.max(existing?.updatedAt ?? 0, now)
• reply-DpTyb3Hh.js ~line 63380: evaluateSessionFreshness() reads the now-stale entry
• pi-embedded-helpers-Q6axDMO3.js ~line 6578: staleIdle = idleExpiresAt != null && params.now > idleExpiresAt — always false because updatedAt was just set to now

Suggested fix

Either:

• Don't update updatedAt in updateLastRoute() (use a separate field like lastRouteAt for delivery routing freshness)
• Or evaluate session freshness before calling recordInboundSession()

Version

OpenClaw 2026.2.3-1, iMessage channel, macOS (arm64)