Edit 2026-04-09: @martingarramon bisected this more precisely the regression actually shipped in v2026.4.1, not v2026.4.8. The issue is the updatedAt: Date.now() write at src/auto-reply/reply/session.ts:521, which runs for all events including heartbeats, causing evaluateSessionFreshness in config/sessions/reset.ts to always see the session as fresh. Related prior reports: #51000, #46539. Open fix attempt: #53014. Leaving the rest of this report unedited for thread continuity.

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Since 2026.4.8, the daily atHour session reset no longer fires, causing long-running sessions to grow without bound across days.

Steps to reproduce

1. Fresh OpenClaw 2026.4.8 install, default config (no overrides to session.reset).
2. Start a session and exchange 10–20 messages.
3. Leave the session idle across a 4:00 AM local boundary on the gateway host (the documented default atHour).
4. Send a new message the next morning.
5. Run /status or /context detail.

For a faster repro: set session.reset.atHour to a value a few minutes in the future, leave the session idle until it passes, then send one more message and check /status.

Expected behavior

Per docs/concepts/session.md (link):

"new session at 4:00 AM local time on the gateway host"

After the reset boundary, /status should show a fresh session with message count near 1. This behaviour has been the documented default since commit 367826f ("feat(session): add daily reset policy", Jan 18 2026).

Actual behavior

The daily reset does not fire. Message count continues from the previous day. Sessions grow monotonically until the provider returns an error or corrupts output.

Observed on one affected session:

contents.length:          639 messages (328 user / 311 model)
total chars in contents:  1,870,544
systemInstruction chars:  130,973
promptTokenCount:         432,902
cachedContentTokenCount:  424,158
finishReason:             MALFORMED_RESPONSE

This was a normal turn mid-conversation. Nothing had pruned history for several days because the daily reset was not firing.

OpenClaw version

2026.4.8

Operating system

Ubuntu 24.04.3 LTS

Install method

npm global

Model

google/gemini-3-flash-preview

Provider / routing chain

Direct Google Generative Language API via OpenClaw's built-in Gemini provider. No intermediate proxy or gateway routing.

Additional provider/model setup details

First-time issue reporter - flagging because this looks like it's affecting users silently. The model choice is incidental: the regression is provider-independent, but gemini-3-flash-preview is where it became visible because the model corrupts output at very large cached contexts (see Actual behavior).

Logs, screenshots, and evidence

**Related upstream items (public):**

- **#58605** — "fix(session): prevent heartbeat/cron/exec events from triggering session reset" (merged April 1 2026, shipped in 2026.4.8). During review, @sharkqwy flagged that because system events update `updatedAt` during persistence, the fix would cause heartbeat runs to suppress idle-based resets indefinitely (the session never becomes stale). Observed behaviour on 4.8 matches that prediction.
- **#61675** — "feat: fire session reset hooks for daily and idle resets" (open, April 6 2026). The existence of this PR indicates reset hooks are not firing for daily resets on 4.8.
- **#61238** — "Critical Data Loss Due to Silent Daily Session Reset" (April 5 2026, filed against 2026.3.13). The opposite failure mode on the prior version: the reporter there is describing the reset firing reliably enough to be a data-loss complaint. Together with the current report, these two issues bracket the regression: reset too aggressive on 3.x, reset not firing at all on 4.8.

**Captured request body:** available on request. Minimal synthetic repro (scripted message loop, empty workspace) can be produced if useful for triage — happy to put one together.

Impact and severity

Severity: high. Silent failure with no error, warning, or log line. Users experience it as bill spikes, intermittent provider errors, or model output quality degradation — none of which naturally point at session reset as the cause.

Frequency: every user on 2026.4.8 whose workflow involves sessions that stay alive across a day boundary. This is the default for most integrations (Telegram groups, Discord threads, Control UI sessions) and probably affects a large fraction of active users.

Consequences observed:

• Cost escalation on providers that charge per-token for cache writes. A 10k-token session that grows to 400k tokens refreshes cache at ~40× the cost when TTL expires. Multiplied across ~8 days since 4.8 shipped and all affected users, this is a meaningful amount of money being burned silently.
• Provider-side failures that mimic model quality issues. Observed MALFORMED_RESPONSE from gemini-3-flash-preview at 424k cached tokens. The natural debugging path is "the preview model is unstable, switch models" - which is wrong; the model is unstable because it's being asked to hold a cached context that should never have been that large.

Workaround available: manual /reset each morning. Not discoverable; users have to already know the regression exists to apply it.

Additional information

No changelog entry in the 2026.4.8 release notes mentions a behaviour change to session reset. #58605 is framed as a fix, not a behavioural change, which is likely why this has gone roughly 8 days without a dedicated bug report despite the broad impact.

Suggested fixes, surgical to structural:

1. Narrow fix(session): prevent heartbeat/cron/exec events from triggering session reset (#58409) #58605's scope so daily atHour evaluation is fully independent of idle/freshness logic and cannot be suppressed as a side-effect of heartbeats updating updatedAt.
2. Land feat: fire session reset hooks for daily and idle resets #61675, which appears to be addressing the same symptom from the other direction.
3. Call the fix out explicitly in the 4.10 (or 4.9.x patch) release notes as a regression fix rather than a silent restoration — users who were burned need to know why their last ~N days of bills were elevated.

Relates to #58605, #61238, #61675.