Can't resume sessions after update on morning of 4/22/2026

[BrainSlugs83]

Describe the bug

After performing a /update this morning, instead of reloading my session in the console, it dumped me back to pwsh.
When trying to manually resume the session, it dumps me back to pwsh.

Trying to resume another session tells me that my session files are corrupt and missing data.compactionTokensUsed.inputTokens which is required.

Basically the update this morning made it so that I cannot resume any previously existing sessions.

Affected version

GitHub Copilot CLI 1.0.35-3

Steps to reproduce the behavior

Type /update.
Observe you are booted to shell and program does not resume.
Observe you are unable to --resume=[GUID] any previous sessions, and if you try to --resume and to pick one from the list, it tells you that the session is corrupt.

Expected behavior

If the session file format changes, older versions of a session should be automatically upgraded.

Additional context

Windows 11 x64 / Windows Terminal

Actual versions from commands:

Windows                        Windows 10 Enterprise N 25H2
PowerShell                     7.6.0

[BrainSlugs83]

I came up with a workaround, where I asked GitHub Copilot CLI to fix it for me -- it looks like this regression is around sessions that have compactions. -- I asked GHCP CLI to figure out why it was failing, and fix those sessions and they seem to be working now -- ideally though, you would not put this burden on the user, and you would just upgrade the file format automatically between versions.

Workaround Result:

● Repaired. Summary:

  Root cause: CLI 1.0.35 added a stricter schema for session.compaction_complete events. Old field names {input, output, cachedInput} inside 
  compactionTokensUsed got renamed to {inputTokens, outputTokens, cacheReadTokens, cacheWriteTokens, reasoningTokens}. Your session had 36 compaction
  events in the old format, so the first one failed validation and killed the resume.

  What I did:

   1. Backed up events.jsonl → events.jsonl.bak-20260422-094146 (and a .preRepair copy too).
   2. Stream-rewrote all 36 compaction events to the new schema (regex rename + added cacheWriteTokens:0, reasoningTokens:0).
   3. Verified line 842 now has valid inputTokens field.

  Try copilot --resume=025e15b8-c7dd-4269-9ff9-20434e3f0772 again. If it works, you can later delete the .bak*, .preRepair, and 
  events-SNACKINTOSH.jsonl.bak files to save ~150 MB. Also worth filing this upstream — the CLI should auto-migrate or tolerate the old schema instead of
  hard-crashing.

❯ It's working, can you fix my other sessions please?

● Repair all sessions with old compaction schema (shell)
  │ $root="$env:USERPROFILE\.copilot\session-state"; $stamp=Get-Date -Format 'yyyyMMdd-HHmmss'; $report=@(); foreach ($dir in Get-ChildItem $root
  │ -Directory) {
  │ $src = Join-Path $dir.FullName "events.jsonl"
  │ if (-not (Test-Path $src)) { continue }
  │ $tmp = "$src.new"…
  └ 49 lines...

● Done. Repaired 16 sessions (31 compaction events total) out of 129 scanned. Every modified file has a .bak-20260422-095112 sibling for rollback. Any of
  those sessions should now resume cleanly.

❯ Why only 16 sessions and not all 129?

● Stats on session compaction state (shell)
  │ $root="$env:USERPROFILE\.copilot\session-state"; $stats=@{WithCompaction=0; Without=0; NewSchema=0; OldSchema=0}; foreach ($dir in Get-ChildItem $root
  │ -Directory) { $f="$($dir.FullName)\events.jsonl"; if (-not (Test-Path $f)) { continue }; $hasComp=$false; $hasOld=$false; $hasNew=$false;
  │ $sr=[IO.StreamReader]::new($f); while(($l=$sr.ReadLine()) -ne $null){ if($l -match '"type":"session\.compaction_complete"'){ $hasComp=$true; if($l -match
  │ '"compactionTokensUsed":\{"input":'){$hasOld=$true} elseif($l -match '"compactionTokensUsed":\{"inputTokens":'){$hasNew=$true} } }; $sr.Close();
  │ if($hasComp){$stats.WithCompaction++} else {$stats.Without++}; if($hasOld){$stats.OldSchema++}; if($hasNew){$stats.NewSchema++} }; $stats
  └ 7 lines...

● Because only 17 sessions ever hit compaction at all — the other 112 were short enough to never trigger a context compaction, so they have no 
  session.compaction_complete events to fix. Of the 17, 16 had the old {input,output,cachedInput} schema (now repaired) and 1 already had the new schema.
  All 129 sessions are now in a resumable state as far as this bug is concerned.