codex cli: the resume-picker list sometimes incorrectly shows "(no message yet)" under conversation

What version of Codex is running?

codex-cli 0.92.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.2-codex

What platform is your computer?

(Windows 11) Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

WSL through Windows Terminal

What issue are you seeing?

⚠️ NOTE: I have already root-caused the issue and validated a functional workaround. See the "Additional information" section for details.

When running codex resume, I see "(no message yet)" for some conversation fields in the picker list. Some of these are inaccurate and there actually is a conversation (my prompts and codex responses).

For example:

Resume a previous session
Type to search
  Updated        Branch                    Conversation
> 6 seconds ago  …dex-20260129-screenshot  (no message yet)
  5 hours ago    …dex-20260129-screenshot  tell me about the png crate using context7
  4 hours ago    dev                       tell me about winit using context7
  5 hours ago    …dex-20260129-screenshot  tell me about thiserror using context7
  6 hours ago    …dex-20260129-screenshot  hello
  4 hours ago    dev                       This project uses Rust libraries winit and wgpu to open a window and render graphics when run with `ca...
  5 hours ago    dev                       (no message yet)

The first option says no message yet, but the corresponding jsonl logs clearly show:

{"timestamp":"2026-01-30T07:50:04.069Z","type":"response_item","payload":{"type":"message","role":"user","content":[{"type":"input_text","text":"summarize src/main.rs"}]}}

It's important to mention that when a thread is affected by this bug, it will not show up in the task history view in the vscode IDE extension (even after restarting).

What steps can reproduce the bug?

The bug can be consistently reproduced by performing enough non-prompt commands at the beginning of a new thread before sending the first prompt.

For example, if the first thing I do is prompt "summarize src/main.rs", the conversation value in the resume-picker will populate correctly. If I instead change the model, approval/permissions, or run shell commands, the conversation value may incorrectly show "(no message yet)".

An easy way to trigger the bug is to just run !ls 10 times in a new thread before sending the first prompt.

What is the expected behavior?

It's expected that the conversation field in the resume-picker is populated correctly with the actual first message the user sent. At the very least, it should not say "no message yet" when there actually has been a message sent.

It's expected that threads with conversation message should always show up in the task history view of the vscode IDE extension.

Additional information

The string "(no message yet)" appears only in 1 place in the entire repo: https://github.com/openai/codex/blob/36f2fe8af94bf678f6653e02bd5e6cd7a558aa21/codex-rs/tui/src/resume_picker.rs#L719

By examining some of the neighboring code, I believe I have root-caused the issue. Tracing back to the fn definition fn head_to_row(item: &ThreadItem) and inspecting the definition of the ThreadItem struct at core/src/rollout/list.rs, I noticed there is a HEAD_RECORD_LIMIT controlling how many jsonl records are processed when filling out the resume-picker table. https://github.com/openai/codex/blob/36f2fe8af94bf678f6653e02bd5e6cd7a558aa21/codex-rs/core/src/rollout/list.rs#L47

The limit is currently set to 10 (https://github.com/openai/codex/blob/36f2fe8af94bf678f6653e02bd5e6cd7a558aa21/codex-rs/core/src/rollout/list.rs#L77 ) which feels too small. The real-life use case in which I ran into this bug is, I started the codex session/thread by switching some approval and permission settings, then ran a shell command, and my first prompt was actually line 11 of the jsonl file. I confirmed this workaround works: I just deleted line 10 which was my shell command, and now my prompt was line 10 of the file, and then, upon rerunning codex resume, the conversation value was populated correctly. I also restarted the codex IDE extension and confirmed my thread shows up in the task history.

Some suggestions:

• The obvious easy fix is to just bump the value up from 10 to, say, 25, though this is obviously fragile and bad for performance. It may be acceptable tech debt to take on at this time since it is very easy and may become obsolete soon anyway.
• A more robust fix might be something like raising a flag whenever the "(no message yet)" case is encountered and only parsing more jsonl lines for those sessions as needed.
• In case of a non-robust fix, at the very least the value shown in the conversation column of the resume-picker should be more helpful, something like "(message not found in first X lines of history)"