What happened?
The JSONL reader ignores parse errors on individual lines. That sounds resilient, but the metadata line is special. If the first metadata line is truncated or malformed, metadata.sessionId and metadata.projectHash may never be set. The loader then falls back to legacy
parsing and returns null. All later valid messages are ignored for listing/resume purposes. A single bad metadata line can make a large conversation disappear from the session list.
packages/core/src/services/chatRecordingService.ts:140
for await (const line of rl) {
if (!line.trim()) continue;
try {
const record = JSON.parse(line) as unknown;
packages/core/src/services/chatRecordingService.ts:232
} catch {
// ignore parse errors on individual lines
}
packages/core/src/services/chatRecordingService.ts:237
if (!metadata.sessionId || !metadata.projectHash) {
return await parseLegacyRecordFallback(filePath, options);
}
What did you expect to happen?
The loader should attempt recovery before giving up. It can use the filename short ID, later $set records, valid message records, or a best-effort reconstructed metadata object. If it still cannot recover, it should quarantine the file instead of letting cleanup delete it. A valid conversation should not be lost because the first line is the only accepted source of identity
Client information
Client Information
Run gemini to enter the interactive CLI, then run the /about command.
╭─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ About Gemini CLI │
│ │
│ CLI Version 0.42.0 │
│ Git Commit 68e2196d5 │
│ Model Auto (Gemini 3) │
│ Sandbox no sandbox │
│ OS linux │
│ Auth Method Signed in with Google │
│ Tier Gemini Code Assist in Google One AI Pro │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯
Login information
Signed in with Google
Anything else we need to know?
No response
What happened?
The JSONL reader ignores parse errors on individual lines. That sounds resilient, but the metadata line is special. If the first metadata line is truncated or malformed, metadata.sessionId and metadata.projectHash may never be set. The loader then falls back to legacy
parsing and returns null. All later valid messages are ignored for listing/resume purposes. A single bad metadata line can make a large conversation disappear from the session list.
packages/core/src/services/chatRecordingService.ts:140
packages/core/src/services/chatRecordingService.ts:232
packages/core/src/services/chatRecordingService.ts:237
What did you expect to happen?
The loader should attempt recovery before giving up. It can use the filename short ID, later $set records, valid message records, or a best-effort reconstructed metadata object. If it still cannot recover, it should quarantine the file instead of letting cleanup delete it. A valid conversation should not be lost because the first line is the only accepted source of identity
Client information
Client Information
Run
geminito enter the interactive CLI, then run the/aboutcommand.Login information
Signed in with Google
Anything else we need to know?
No response