Bug type

Crash (process/app exits or hangs)

Summary

Session transcript persistence fails after session reset: 6 hours of conversation history lost despite successful skill file creation, indicating a critical race condition in session management.

On March 13, 2026, a 6-hour conversation session was lost after a session reset event.
The old session file was renamed with .reset. suffix, but no new session file was created
to continue the transcript. Evidence (skill files created at 19:37-20:51) proves the
conversation occurred, but the transcript was not persisted. Root cause appears to be
a race condition or write-lock timeout during session reset.

GITHUB-ISSUE-SESSION-LOSS.md

Steps to reproduce

Steps to Reproduce

Note: This appears to be a race condition and may not reproduce reliably.

1. Start a long-running session (6+ hours)
2. During the session, create multiple files via tools (skills, memory files)
3. Experience network instability (WebSocket disconnect with code=1006)
4. Observe session reset in logs: [acp] force reset current assistant stream
5. Continue conversation after reconnection
6. Expected: New session file created, transcript continues
7. Actual: No new session file created, transcript lost

Key Indicators in Logs:

• [session-write-lock] releasing lock held for >720000ms
• Multiple closed code=1006 WebSocket errors
• .reset. file exists but no subsequent .jsonl file

Expected behavior

Expected Behavior

1. When a session reset occurs:

   • Current session file should be archived with .reset.{timestamp} suffix
   • A new session file should be immediately created with a new UUID
   • Conversation should continue seamlessly

2. Session persistence guarantees:

   • Every message exchange should be written to disk within 30 seconds
   • No data loss even during network interruptions or gateway restarts
   • On abnormal termination, unsaved data should be recoverable from buffer

3. File continuity:

   • After reset: old-session.jsonl → old-session.jsonl.reset.{timestamp} + new-session.jsonl
   • All historical conversations should be reconstructable from session files

Actual behavior

Actual Behavior

1. Session was reset at 20:19:34 (file renamed with .reset. suffix) ✅
2. No new session file was created ❌
3. Subsequent conversation (19:37-20:51) was not persisted ❌
4. ~6 hours of conversation history lost permanently ❌
5. Skill files created during the period exist, proving conversation occurred

OpenClaw version

2026.3.12 (6472949)

Operating system

macOS 26.2 (Build 25C56)

Install method

No response

Model

kimi-coding/k2p5

Provider / routing chain

openclaw -> kimi-bridge -> acp -> kimi-coding/k2.5

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response