thread-store: a single BOM-prefixed rollout .jsonl fails the entire thread read and blocks message creation

Open 💬 2 comments Opened Jun 14, 2026 by andrewkangkr

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).

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗