openclaw - 💡(How to fix) Fix [Bug]: Unexpected sessionFile reset behavior [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Session resets do not result in a new sessionFile every reset period - sessionId resets, but sessionFile gets set, which is then persisted across every reset going forward.

Steps to reproduce

1. Use a direct-chat session routed to agent:main:main.
2. Confirm session.resetByType.direct = { mode: "daily", atHour: 10 } is active.
3. Let the session have an explicit sessionFile in sessions.json.
4. Let a reset boundary pass, or inspect a session after reset.
5. Observe that sessionId changes but sessionFile still points to the old transcript path.
6. Remove sessionFile from agent:main:main in sessions.json.
7. Send one new message.
8. Observe that OpenClaw regenerates sessionFile as /data/agents/main/sessions/<current-sessionId>.jsonl.

Expected behavior

When a reset rotates sessionId, transcript path should roll too. The active transcript file should follow the current sessionId.

Actual behavior

sessionId rotates, but an already-persisted sessionFile is preserved across resets. This keeps writing into an older transcript file until sessionFile is manually removed.

OpenClaw version

2026.4.15

Operating system

Linux 6.12.47-fly (x64)

Install method

docker

Model

gpt 5.4

Provider / routing chain

openclaw -> codex -> openai

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

• Affected users/systems/channels: Direct-chat sessions using stable session keys like agent:main:main, especially when transcript shape matters for downstream tooling.
• Severity: Annoying to moderate. Confusing session behavior, breaks expectation that reset implies fresh transcript file.
• Frequency: Deterministic once sessionFile is explicitly persisted and then preserved across resets.
• Consequence: Harder debugging, larger long-lived transcript docs, worse transcript hygiene for exports/indexing, possible extra QMD churn on long constantly-updated transcript files.

Additional information

• The primary pain point is around QMD. It appears to trip up more on long, constantly-updated session files than on smaller, stable ones.
• Direct observation showed that removing sessionFile causes OpenClaw to regenerate the correct default path on the next message.
• This suggests the problem is not transcript creation itself, but over-preservation of an old explicit sessionFile across resets.
• This matters because smaller session docs are easier to inspect and work with.