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
- Use a direct-chat session routed to
agent:main:main.
- Confirm
session.resetByType.direct = { mode: "daily", atHour: 10 } is active.
- Let the session have an explicit
sessionFile in sessions.json.
- Let a reset boundary pass, or inspect a session after reset.
- Observe that
sessionId changes but sessionFile still points to the old transcript path.
- Remove
sessionFile from agent:main:main in sessions.json.
- Send one new message.
- 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.
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
agent:main:main.session.resetByType.direct = { mode: "daily", atHour: 10 }is active.sessionFileinsessions.json.sessionIdchanges butsessionFilestill points to the old transcript path.sessionFilefromagent:main:maininsessions.json.sessionFileas/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 currentsessionId.Actual behavior
sessionIdrotates, but an already-persistedsessionFileis preserved across resets. This keeps writing into an older transcript file untilsessionFileis 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
agent:main:main, especially when transcript shape matters for downstream tooling.sessionFileis explicitly persisted and then preserved across resets.Additional information
sessionFilecauses OpenClaw to regenerate the correct default path on the next message.sessionFileacross resets.