VS Code Codex "All tasks" list is dropping valid sessions and showing a non-recency order

I am seeing sessions that definitely exist in local Codex storage but do not appear in the VS Code Codex task list, even when the picker is set to All tasks.

This does not look like the sessions are being deleted. It looks like the VS Code client is applying a buggy filter/group/sort transform on top of the real session inventory.

Environment

• VS Code Insiders
• OpenAI Codex / ChatGPT extension: openai.chatgpt
• Local Codex storage inspected:
• ~/.codex/session_index.jsonl
• ~/.codex/state_5.sqlite

What I am seeing

• Some sessions show up in VS Code Codex.
• Some sessions do not show up in VS Code Codex at all, even though they are present in the local Codex databases.
• The missing sessions are not archived.
• The missing sessions can still exist in Codex local storage, and in some cases I can still see them in other Codex surfaces.

One concrete example:

• Visible in VS Code: Handle invalid session failure
• Missing from VS Code: Evaluate browser-use options

Both exist in local storage.

Evidence that the missing sessions are real and healthy

From session_index.jsonl:

{"id":"019d4b69-25d1-7be2-b5f4-8c4234ed5dee","thread_name":"Evaluate browser-use options","updated_at":"2026-04-01T23:39:24.362613Z"}
{"id":"019d4f6d-fa9c-7913-a6c7-74394ee12573","thread_name":"Handle invalid session failure","updated_at":"2026-04-02T18:22:02.529171Z"}

From the main threads table:

019d4b69-25d1-7be2-b5f4-8c4234ed5dee|2026-04-01 16:37:55|2026-04-01 16:50:49|vscode|openai|/Users/.../Downloads/SetupOpenClaw|...|archived=0
019d4f6d-fa9c-7913-a6c7-74394ee12573|2026-04-02 11:21:40|2026-04-02 13:01:40|vscode|openai|/Users/.../Dropbox/Programming/Python/MyApp|...|archived=0

The missing thread is not malformed in an obvious way:

• it exists in session_index.jsonl
• it exists in state_5.sqlite
• it has source='vscode'
• it has archived=0

Evidence that this is not just one bad session

I found multiple sessions that exist in local Codex storage but are absent from the VS Code task list:

• Evaluate browser-use options
• Inspect OpenClaw logs
• Add enriched fields to reports
• Locate app list
• Fix Telegram group replies

At least one of these is especially useful as a control:

• Inspect Unraid Docker config is visible in VS Code
• Evaluate browser-use options is missing in VS Code

Those two threads have very similar metadata:

• both are source='vscode'
• both are under the same cwd family: /Users/.../Downloads/SetupOpenClaw
• both are unarchived
• both were created by the same desktop-style path in rollout metadata
• both have the same extra dynamic tool entry (read_thread_terminal)

So this does not look like a simple "desktop-origin sessions are hidden" rule.

Evidence that the VS Code list is not a plain recent-sessions list

The order shown in the VS Code picker does not match the actual updated_at order from local storage.

Example from local session_index.jsonl ordering:

Review experiment matrix status   2026-03-28T03:57:59Z
Check SMART for cache issues      2026-03-28T05:45:25Z
Migrate PostgreSQL 13 to 18       2026-03-28T05:51:15Z

But in the VS Code UI I saw:

Migrate PostgreSQL 13 to 18
Diagnose missing Unraid shares
Check SMART for cache issues

That is not consistent with a direct updated_at desc render.

Another example:

• Document using_appium cache cleanup is newer than Locate snapshot workflow in local storage
• but Locate snapshot workflow appears above it in the UI

So the task list is definitely being transformed client-side after loading.

Pattern I found

The visible sessions in the VS Code picker are heavily concentrated under a handful of roots:

• MyApp
• debugging_wyze_thingino
• AppExportImport
• FixingUnraid

But most of the missing examples are under roots that the picker seems to treat differently:

• SetupOpenClaw
• BCBS Provider Search
• appManagement

This is not a complete rule, because one SetupOpenClaw thread does appear while other SetupOpenClaw threads do not. That makes it look less like an intentional filter and more like a buggy merge/filter/grouping step.

Current theory

The VS Code Codex task picker is not rendering the raw stored session list directly.

It appears to have a client-side model that does some combination of:

• filtering
• grouping by workspace/project
• sorting
• relevance selection

and that model is dropping valid sessions or mis-merging them.

The bug seems to be in the VS Code client list model, not in Codex local persistence itself.

Why I think this is not a storage corruption issue

• missing sessions still exist in session_index.jsonl
• missing sessions still exist in state_5.sqlite
• missing sessions are not archived
• nearby visible sessions can have essentially the same metadata shape as nearby missing sessions

What would help

• A debug view or logging for how the VS Code task list is built from local sessions
• A way to compare "raw stored sessions" vs "sessions after UI filters"
• A fix so All tasks truly shows all tasks, in stable recency order

Minimal repro description

1. Create several Codex sessions across multiple folders/projects.
2. Confirm they exist in local storage under:

~/.codex/session_index.jsonl
~/.codex/state_5.sqlite

1. Open the VS Code Codex task picker with All tasks.
2. Observe that some valid sessions are missing.
3. Observe that the displayed order does not match local updated_at ordering.