VS Code recent-task picker hides valid Codex threads when first user message is an attachment wrapper with empty request body

What version of the IDE extension are you using?

26.616.51431

What subscription do you have?

pro

Which IDE are you using?

VS Code

What platform is your computer?

_No response_

What issue are you seeing?

I hit a case where a valid local Codex thread was not shown in the VS Code extension’s recent-task picker, even though the thread existed, was readable by ID, and appeared in other app-server listing modes.

The affected thread had a transcript where the first real user message was an attachment-wrapper message like:

# Files mentioned by the user:

## .../pasted-text.txt

The attached pasted text file(s) contain the user's request. Read and act on that content.

## My request for Codex:

The ## My request for Codex: section was empty, while the actual task was in the attachment. The thread had correct metadata in .codex/state_5.sqlite and .codex/session_index.jsonl.

Observed behavior:

• thread/read worked for the thread ID.
• thread/list with sortKey: "recency_at" returned the thread.
• thread/list with sortKey: "created_at" or "updated_at" did not return it.
• The VS Code recent-task picker appears to use thread/list with sortKey: "created_at", so the thread was invisible in the UI.
• After manually filling the missing prompt text into the transcript wrapper, the same thread/list query returned the thread and it appeared in the VS Code picker.

Expected behavior:

The VS Code recent-task picker should show valid readable threads even when the initial user request came from an attachment wrapper and the inline ## My request for Codex: section is empty.

Why this matters:

The thread was not corrupted and could be resumed/read by app-server. It was only excluded from the specific list path used by the VS Code UI, making it look like the task disappeared.

Environment:

• Codex VS Code extension: openai.chatgpt-26.616.51431-linux-x64
• Codex CLI/app-server: 0.142.0-alpha.6
• Remote VS Code server on Linux
• Local Codex state under ~/.codex

Potential fix:

The list-building path should not reject threads solely because the first inline user-message wrapper has an empty request section. It should either fall back to DB metadata/title/preview, attachment metadata, or the readable thread contents used by thread/read.

What steps can reproduce the bug?

first paste a very long prompt, the prompt will be automatically put into a txt file.
then, run it.
then, after it finished, close and reopen the window, that session disappeared

What is the expected behavior?

_No response_

Additional information

_No response_