Summary

session.maintenance controls (rotateBytes, maxDiskBytes, maxEntries) apply to sessions.json (the session index file) but have no effect on individual transcript .jsonl files. These files can grow without bound, eventually causing gateway CPU 100% and unresponsiveness.

Environment

• OpenClaw version: v2026.4.12
• Node: v25.8.1
• OS: Darwin 25.4.0 (arm64, Apple Silicon)
• Affected session types: topic-bound group chat sessions (e.g. Telegram forum topics)

Current config (session.maintenance)

{
  "pruneAfter": "30d",
  "maxEntries": 500,
  "rotateBytes": "10mb",
  "maxDiskBytes": "500mb",
  "highWaterBytes": "400mb",
  "mode": "enforce"
}

Observed behavior

With the above config, individual .jsonl transcript files grew to:

• daily-devops topic-2.jsonl → 113 MB (25,927 lines)
• dev-tl session.jsonl → 266 MB
• dev-tl session.jsonl → 56 MB
• daily-collector topic-8.jsonl → 36 MB

The rotateBytes: "10mb" setting had zero effect on any of these files.

Impact

When daily-devops/topic-2.jsonl reached 113 MB, gateway entered CPU 100% and became completely unresponsive. Manual intervention was required: archive the file and restart gateway.

Root cause

rotateBytes rotates sessions.json (the index), not transcript .jsonl files. There is no mechanism to cap or rotate individual transcript files. For long-running topic-bound sessions (group chats, forum topics), these files grow indefinitely because:

1. Every message, tool call, and tool result is appended in full
2. Large tool results (e.g. sessions_list, file reads) are not truncated before write
3. No maintenance hook checks transcript file sizes

This is distinct from issue #18572 (which is about sessions.json rotation race condition).

Expected behavior

session.maintenance should include controls for transcript .jsonl files, such as:

• transcriptRotateBytes: rotate (archive) a transcript when it exceeds a size threshold
• transcriptMaxLines: cap lines per transcript file
• Or: apply rotateBytes to transcripts as well, not just sessions.json

Workaround

Running a nightly cron that scans all agent session directories and archives .jsonl files exceeding 10 MB.

Related

• Issue sessions.json rotation (rename) + unlocked store read can cause random new sessionId ("memory wipe") without /new #18572: sessions.json rotation race condition (different issue, same config surface)