Long-lived session shows as corrupted on resume despite valid events.jsonl

[KarnikJain]

Describe the bug

A session with heavy usage (204 premium requests, 34 user messages, 3 segments across resumes) shows as corrupted when attempting to resume. Investigation shows the events.jsonl file is structurally valid:

• All 8,366 lines parse as valid JSON (no SyntaxError)
• File ends cleanly with a newline
• Proper session.start → session.shutdown structure
• session.db passes SQLite PRAGMA integrity_check
• workspace.yaml is well-formed

The only anomaly is file size: 18 MB / 8,366 event lines accumulated over 3 session segments (1 start + 2 resumes).

Affected version

• Created with: GitHub Copilot CLI 1.0.9
• Resume attempted with: GitHub Copilot CLI 1.0.10
• Model: Claude Opus 4.6 (1M context)

Session diagnostics

Metric	Value
Session ID	be25adf7-5860-40ac-bfb6-2eb178a0f848
events.jsonl size	18,427,560 bytes (8,366 lines)
Session segments	3 (start → shutdown → resume → shutdown → resume → shutdown)
User messages	34
Assistant turns	589
Tool executions	2,103
Premium requests	204 total (24 + 6 + 174 across segments)
Sub-agents spawned	38

Session segment boundaries

Line     1: session.start     ts=2026-03-20T06:02:49
Line  2103: session.shutdown  shutdownType=routine  premiumRequests=24
Line  2104: session.resume    ts=2026-03-20T16:15:42
Line  2393: session.shutdown  shutdownType=routine  premiumRequests=6
Line  2394: session.resume    ts=2026-03-21T04:00:38
Line  8366: session.shutdown  shutdownType=routine  premiumRequests=174

Workaround applied

Trimmed events.jsonl to only the last segment (lines 2394–8366) with a synthetic session.start replacing the session.resume. Reduced from 18 MB → 14 MB.

Expected behavior

1. Sessions with valid events.jsonl should not show as corrupted regardless of file size
2. If there is a size/event-count limit, the CLI should proactively compact or checkpoint the events file (e.g., via /compact) before it becomes unresumable
3. Better error messaging — "corrupted" is misleading when the file is structurally valid; a message like "Session too large to resume (18 MB). Try /compact" would help

Possible root causes

• No size/event limit handling: The resume logic may OOM or timeout parsing 18 MB of events
• Version mismatch (1.0.9 → 1.0.10): Schema changes between versions may reject older event formats
• Missing auto-compaction: Long sessions with many sub-agents and tool calls accumulate events without any pruning

Related issues

• Failed to resume session: Error: Session file is corrupted #1864 — Session corrupted after power loss (different root cause: invalid JSON)
• Session file corrupted: raw U+2028/U+2029 in events.jsonl breaks JSON.parse() on /resume #2012 — Unicode U+2028/U+2029 corruption (different root cause: encoding)
• copilot cli in wsl spinning on the cpu with an unresponsive tui #2208 — CPU spinning on large sessions (possibly same underlying issue: large state)
• Usage data is incorrect when sessions are resumed #524 — Usage data incorrect on resume (session resume handling)

Additional context

Environment: Linux DevBox (WSL-like), long-running FunOS firmware development session with extensive tool usage (builds, grep, file edits, sub-agents).

[KarnikJain]

Update: Session repaired and root cause narrowed

The repair worked. After aggressive trimming, the session resumes successfully.

What fixed it

1. Trimmed events.jsonl from 8,366 lines (18 MB) → 101 lines (183 KB) — kept only the last 5 user messages + their assistant turn events, removing all hook events and earlier segments
2. Cleaned the session.start event — removed extra fields (repaired, originalStartTime, repairNote) and updated copilotVersion from 1.0.9 to 1.0.10

Root cause analysis

The session accumulated 18 MB of events across 3 resume segments (204 premium requests, 34 user messages, 2,103 tool executions, 38 sub-agents). The CLI either:

• OOMs or times out parsing 18 MB of events on resume
• Has a size/line limit that isn't enforced at write time

The repaired 183 KB file resumes instantly and loads all 3 MCP servers + 45 skills successfully.

Recommendations

1. Auto-compact: The CLI should automatically compact/checkpoint events.jsonl when it exceeds a threshold (e.g., 5 MB or 2,000 events)
2. Better error messaging: Instead of "corrupted", say "Session too large to resume (18 MB). Run /compact first or start a new session."
3. Graceful degradation: On resume failure, offer to resume from the last checkpoint or trim to recent turns automatically

[KarnikJain]

Hit this again on a different session (5fecb21a-8cde-4fa1-ac96-934505967671) with v1.0.16. This time it was compounded with #2012 (U+2028 in user message). Filed #2490 with full diagnostics, error progression, and a working manual workaround.

Key new data points:

• 20MB / 10,667 events across 10 segments — even larger than the 18MB session in this issue
• Largest single event: 1.6MB — a hook.start event containing SharePoint binary file data via MCP. Individual event size caps would help.
• The two bugs mask each other: fixing the size issue reveals U+2028, fixing U+2028 reveals missing session.start after trimming. Users need to fix all three in the right order.

[jespinal]

Hello, there:

I stumbled upon this issue too a few minutes ago.

I gave Copilot the session summary title and a link to this Github issue, and it fixed the session file by, according to it, "replacing the raw bytes \xe2\x80\xa8 (U+2028 in UTF-8) with the ASCII bytes for \u2028 (the JSON escape sequence: \, u, 2, 0, 2, 8)". The fix worked.

I was writing in Spanish, and used plenty of accented + UTF8 characters.

GitHub Copilot CLI 1.0.17