Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

OpenClaw automatically resets all sessions daily at 4:00 AM local time. This behavior is not disclosed to the user during normal operation, and there is no discoverable way to disable or be warned about it .

Steps to reproduce

Steps to Reproduce

1. Install and run OpenClaw with default settings
2. Use the system for multiple days in a row
3. Wait for 4:00 AM
4. Observe: Session resets, all context lost, no warning given

Expected behavior

Expected Result

At minimum: Before resetting a session, the system MUST:

1. Display a clear warning (e.g., "Session will reset in 5 minutes, losing all context")
2. Provide an option to cancel or postpone the reset
3. Offer a way to save/export the current session

Ideally: The user should have full control over when a session resets. Automatic destructive actions should never happen silently.

Technical Context

• Documentation confirms daily 4:00 AM reset as default behavior
• GitHub Issue Feature request: add session.reset.mode="off" for long-running context continuity #29536 requested an "off" mode, but this is not discoverable to average users
• Even if mode: off exists, users cannot know about it without deep research

Actual behavior

• The system deletes session data without asking
• No warning appears before the reset occurs
• Backups are created but cannot be restored into the active session

OpenClaw version

2026.3.13

Operating system

Windows

Install method

No response

Model

claude-sonnet 4.6

Provider / routing chain

OpenClaw Version: 2026.3.13 OS: Ubuntu 24.04 LTS Gateway Mode: local VM: Genspark VM (Azure Japan East)

Additional provider/model setup details

Why This Is Critical

1. Silent data destruction — No warning, no confirmation, no chance to intervene
2. Unreasonable discoverability — Users should not have to read external docs to avoid data loss
3. Restore impossible — Backups exist but cannot be loaded back into the chat
4. Real damage confirmed — 8+ resets, 15,000+ messages lost over 1 week

Logs, screenshots, and evidence

Impact and severity

As a result, between March 24 and March 31, 2026, over 8 MB of conversation data and an estimated 15,000+ messages were permanently lost across 8+ automatic resets.

Additional information

Proposed Solution

1. Immediate: Add an in-client warning before any automatic session reset (countdown + cancel option)
2. Default behavior change: Disable automatic destructive resets by default, or make them require explicit user opt-in
3. Restore feature: Implement a /restore command to load previous backups into active session
4. Documentation: Add prominent, unavoidable notice in the first-time setup flow