thread-store: a single BOM-prefixed rollout .jsonl fails the entire thread read and blocks message creation
Summary
A single rollout .jsonl whose first bytes are a UTF-8 BOM (EF BB BF) causes thread-store to error out, and this blocks new message/turn creation entirely — not just for that one thread. The store appears to scan rollouts and hard-fails on the first malformed file instead of skipping/isolating it.
Environment
- Codex Desktop 0.140-alpha, Windows 11
~/.codex/sessions/.../rollout-*.jsonl
Error
failed to read thread: thread-store internal error: failed to read thread \\?\C:\Users\<user>\.codex\sessions\2026\06\03\rollout-...-<id>.jsonl: rollout at ... does not start with session metadata
Root cause
The file's first line is valid session_meta JSON, but a 3-byte UTF-8 BOM was prepended (by an external tool that re-saved the file). The metadata check fails because the line doesn't start with {. Raw first bytes: EF BB BF 7B 22 74 ... (<BOM>{"t...).
Impact
One corrupt/BOM rollout makes the whole thread-store read fail, so the user can no longer send any message in Codex Desktop until the offending file is located and fixed.
Expected
- Tolerate a leading UTF-8 BOM when parsing rollout metadata, or
- Skip/quarantine an unreadable rollout and continue, instead of failing the entire store and blocking message creation.
Workaround
Strip the 3-byte BOM from the offending .jsonl (so the first byte becomes 0x7B).
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗