Session transcripts are only guaranteed to be fully flushed on clean exit; power loss or crash can lose the tail of a conversation

Session files in %USERPROFILE%\.jcode\sessions are not written to disk on every turn. On-disk content can lag the live conversation by a long time, and only a clean session exit appears to guarantee a complete file. An unexpected power loss or crash can therefore silently lose the most recent portion of a conversation.

Observed behavior (Windows x64, jcode v0.79.1)

1. While a session is active, its file is sometimes seen in an append-only JSONL form (first line {"meta": {...}, "append_messages": [...]}, one message per following line). At rest it is rewritten as a single JSON object. This suggests a buffered/lazy flush design rather than per-turn persistence.
2. The on-disk content can lag far behind the conversation. Concrete case: at 18:55 UTC the active session file contained 1,588 messages with the last one timestamped 05:44 UTC, while the conversation had continued past that point for hours. A subsequent archive of that file silently captured only content up to 05:44.
3. The file's mtime can be newer than the newest message inside it (a rewrite happened without the latest messages being included), reinforcing that flushes are event-driven and not incremental.
4. The session status field distinguishes Active, Closed, and Crashed (5 of 132 files in this install carry a Crashed record), confirming abnormal terminations do occur.

Impact

• Any tooling that consumes the session file (archiving, backup, resume) can silently operate on incomplete data. The user only discovered truncated archives after inspection; the UI gave no indication the file was stale.
• On power loss or crash, the tail of the conversation (potentially hours of work) is lost.

Suggested remedies (any of these would help)

• Flush the session file at each turn end (or at minimum after every tool call), making the on-disk copy incrementally complete.
• If buffering is intentional for performance, expose an explicit flush (e.g. a /flush or /save-session command) and document the flush policy.
• On abnormal exit paths (crash handler), attempt a final flush of buffered transcript data, similar to the Crashed status bookkeeping that already exists.

Environment

• jcode v0.79.1 (993da322e), Windows x64
• Sessions directory: %USERPROFILE%\.jcode\sessions

Reproduce the lag by observing a live file under %USERPROFILE%.jcode\sessions while a session receives several turns and tool calls. Trace the session persistence and abnormal-exit paths, including the status bookkeeping that records Crashed. Done means the on-disk transcript is incrementally current or has a documented explicit flush policy, and crash handling does not silently lose the conversation tail.