Session permanently lost after uncontrolled laptop shutdown — null bytes + metadata corruption still unhandled in v1.0.35

[jfilcik]

Describe the bug

Session becomes permanently unresumable after an uncontrolled laptop shutdown (e.g., battery death, forced restart, BSOD). The session directory is fully intact on disk — workspace.yaml, session.db, plan.md, 3 checkpoints — but the CLI refuses to load it. Neither /resume nor manual metadata repair restores the session.

This seems to be the same class of crash-resilience issue described in #2217 (trailing null bytes in events.jsonl), but triggered by a broader scenario: an uncontrolled OS-level shutdown rather than just a process kill. The OS shutdown also corrupts vscode.metadata.json and leaves stale lock files, creating a triple failure that manual repair of any single file cannot fix.

Environment

• Copilot CLI: v1.0.35-6
• OS: Windows 11 / x86_64
• Model: Claude Opus 4.6
• Session age: 4 days of active use (2026-04-19 → 2026-04-23), 20 user turns, 3 checkpoints

Session diagnostics

Metric	Value
Local Session ID	13f72ef8-d872-46f3-9459-c5f08184df08
Cloud Session ID	f71fc429-fe0a-4412-b3ed-407d0b7c6f48
events.jsonl size	8.78 MB (3,667 events)
Trailing null bytes	1,206
Checkpoints	3 (all intact)
workspace.yaml	Intact
session.db	Intact (20 KB)
plan.md	Intact

What happened

Laptop underwent an uncontrolled shutdown while the session was mid-execution (turn 13). On reboot, three things were corrupted:

1. events.jsonl — 1,206 trailing null bytes from buffered I/O that never flushed. The last valid event is assistant.turn_start for turn 13; the turn never completed.
2. vscode.metadata.json — Written as {} (empty object) instead of the expected writtenToDisc/firstUserMessage/customTitle fields.
3. Stale lock files — inuse.14004.lock and inuse.59196.lock left behind from the dead processes.

Steps to reproduce the behavior

1. Have an active Copilot CLI session with conversation history and checkpoints
2. Force an uncontrolled OS shutdown (pull power, force restart, or let battery die) while the session is actively executing a turn
3. Reboot and attempt /resume <session-id>
4. Session fails to load

Recovery attempts (all failed)

1. /resume 13f72ef8... → session not found
2. From a new Copilot session, asked Copilot to diagnose and repair:
   • Removed stale lock files (inuse.14004.lock, inuse.59196.lock) ✅
   • Repopulated vscode.metadata.json with correct fields from workspace.yaml ✅
   • Session still cannot be resumed ❌
3. The null bytes in events.jsonl remain the blocking issue — the CLI treats the entire session as corrupted

Expected behavior

The CLI should be resilient to uncontrolled shutdowns:

1. On write: Use atomic writes (write-then-rename) or fsync for events.jsonl and vscode.metadata.json to prevent partial/empty writes
2. On resume: Strip trailing null bytes, drop incomplete last event, clean stale locks, and resume — ideally from the latest checkpoint
3. Fallback: If full repair isn't possible, offer copilot session repair <id> (as proposed in Session resume permanently broken by combined large events.jsonl + U+2028 corruption (reproducer + workaround) #2490) rather than silently refusing to load a session with 3,667 valid events and 3 checkpoints

Related issues

• Copilot cli needs to be more resilient to crashes/unexpected shutdown and recover from them better. #2217 — Same null-byte corruption pattern, reported at v1.0.10, still present at v1.0.35-6
• Session resume permanently broken by combined large events.jsonl + U+2028 corruption (reproducer + workaround) #2490 — Compound corruption (null bytes + U+2028 + oversized events.jsonl), proposes copilot session repair command

Additional context

This is particularly painful for long-running sessions with significant accumulated context. The session had 20 user turns across 4 days of OfficeQA benchmark evaluation work, with 3 checkpoints marking major milestones. All the data to resume exists on disk — the CLI just can't tolerate the crash artifacts.

The fact that this same null-byte issue was reported 14 CLI versions ago (#2217 at v1.0.10, now v1.0.35-6) and is still not handled suggests this needs prioritization, especially since uncontrolled laptop shutdowns are a common real-world event (battery, Windows Update restarts, BSODs, etc.).