migrate-rollouts reports nonempty legacy flat rollout files as empty (invalid_session_metadata)

Finding: In one external report against codex-cli 0.162.1 (official Homebrew install, Darwin arm64), 22 nonempty 2025 legacy flat-format rollout files were reported as empty by codex migrate-rollouts. They were also flagged by codex doctor as having no usable header record. Source: https://github.com/openai/codex/issues/52904. This is an external report only; KFA did not reproduce it. Reported details: The reporter says every line in all 22 files parses as JSON. The first record has id, timestamp and instructions fields, and later records hold response items directly, without the session_meta/payload wrapper. The files total 15,967,874 bytes. Three contain only the metadata record and 19 contain later records (https://github.com/openai/codex/issues/52904). Observed behavior: codex doctor --json showed state.rollout_db_parity as a warning with 22 rollout DB scan errors, 0 malformed file names, scan cap not reached and 0 stale rows. The per-file error was a message that the rollout has no usable header record. Running codex migrate-rollouts --thread <id> --json without --apply returned status failed, failure_reason invalid_session_metadata and bytes_processed 0 for all 22. The message said the rollout is empty (https://github.com/openai/codex/issues/52904). Interpretation, which is a hypothesis rather than confirmed cause: the reporter's evidence suggests the migration path does not recognize the legacy flat header, and the empty-file wording misdescribes a format-recognition failure. No maintainer has confirmed this. The reporter linked the v0.162.1 source files thread_inventory.rs, rollout_migration.rs and line_parser.rs as relevant, but the supplied content does not include any analysis of them. Expected behavior per the reporter: distinguish empty files from unsupported legacy formats with an accurate message. If the format is in scope, provide an official migration path that preserves the content. Status: The issue is open. The supplied sources show no maintainer response, workaround, fix commit or released fix. Whether the legacy flat format is meant to be supported is unknown. Only dry-run behavior was reported, and --apply was not tried. Practical takeaway: if a similar failure appears, the "is empty" message may not mean the file is empty. Check file size and JSON validity before concluding data loss. The reporter left the originals untouched, which is a cautious approach, but this is not a verified remedy.