[IDE / VS Code] Sessions misses recently updated conversations because provider limits by created_at

[joshmouch]

Surface

• VS Code 1.129.1 (arm64, macOS)
• Marketplace extension: openai.chatgpt 26.5715.61943
• View: VS Code/Copilot Sessions, sorted by Updated

This is a VS Code extension report, not a Codex Desktop report. The installed extension has no public repository or issue URL in its Marketplace manifest; I am filing here because openai/codex is the public Codex engineering tracker. Please route it to the IDE-extension owner if that is a separate internal component.

Actual behavior

The Sessions view cannot show many older conversations that were updated recently. Selecting Updated in VS Code does not fix this.

Root cause observed in the shipped extension

The extension registers VS Code's ChatSessionItemProvider, then calls the Codex app server:

{
  "limit": 50,
  "cursor": null,
  "sortKey": "created_at",
  "archived": false,
  "useStateDbOnly": true
}

It maps only the result's creation time into the VS Code session item:

const createdAtMs = Number(thread.createdAt) * 1000;
return { id, resource, label, timing: { startTime: createdAtMs } };

Therefore VS Code receives only the 50 newest-created candidates. Any conversation created before that cutoff is absent from the provider response, even if it was updated today. UI-side Updated ordering can only reorder the already truncated set.

Expected behavior

A Sessions view sorted by Updated should receive the most recently updated conversations, including older conversations with new activity. The provider should request activity-based ordering/pagination and provide appropriate activity metadata, or use another contract that preserves this user-visible semantic.

Independent secondary observation

The same request uses useStateDbOnly: true. On this machine, ~/.codex/session_index.jsonl contained valid July 20 sessions missing from ~/.codex/sqlite/codex-dev.db table local_thread_catalog, so state-only filtering can be a second source of omissions. This is distinct from the primary created_at/limit defect.

Requested follow-up

Please confirm the owner and intended thread/list contract for IDE history. I would like to prepare a focused fix with regression tests, but I understand that the public Codex repository accepts external PRs only by maintainer invitation.

[joshmouch]

Proposed fix and PR-ready scope

To make the requested change concrete, I propose the following, subject to maintainer confirmation of the app-server protocol and the VS Code session API semantics.

1. Return candidates by recent activity, not creation. The IDE provider should request a recency/activity ordering from thread/list (for example sortKey: "updated_at", if that is the supported value), preserving cursor pagination rather than hard-coding a creation-ordered first page.

2. Preserve activity metadata in the IDE session item. Extend/use the thread-list result to carry the canonical last-updated timestamp and map it to the supported VS Code chat-session timing/metadata field used by the host's Updated sort. Do not present createdAt as the only time signal for an activity-sorted surface.

3. Cover the boundary with regression tests. Add a fixture with at least 51 threads where one old-created thread has the newest updated_at. Assert that the IDE-facing provider includes that old-but-recently-updated thread in the first page and that the returned item exposes its activity time. Also retain a case for a thread present in session_index.jsonl but absent from local_thread_catalog, to define the expected useStateDbOnly reconciliation/fallback behavior separately.

This produces two independently reviewable fixes:

• primary: correct the IDE provider's bounded result ordering and updated-time projection;
• secondary: ensure state-only catalog reconciliation does not omit valid indexed conversations.

If the IDE extension source is private, please identify the owning internal component and apply this as an internal change. If the relevant thread/list behavior and tests belong in this public repository, please invite an external PR against the agreed owner and contract.

[joshmouch]

Correction: thread/list already has the necessary abstract data and sort keys

I verified the current public app-server v2 schema and need to narrow the proposed fix further. ThreadListResponse.data already returns full Thread values with both required fields:

Thread {
  createdAt: number; // Unix seconds when created
  updatedAt: number; // Unix seconds when last updated
  // ...
}

ThreadSortKey already supports:

"created_at" | "updated_at" | "recency_at"

Therefore the primary issue does not require extending the app-server contract or adding a new provider-neutral summary type. The required abstraction already exists at the public boundary.

The VS Code extension is the lossy adapter. Its current code:

1. requests thread/list with sortKey: "created_at" and limit: 50;
2. converts each returned Thread into an internal summary retaining only createdAt;
3. maps only that value to VS Code timing.startTime.

The focused primary repair should therefore be in the IDE extension:

• request sortKey: "updated_at" or the maintainer-preferred existing "recency_at";
• retain both existing fields in its internal session summary;
• map createdAt and updatedAt through the host adapter (startTime / endTime, subject to VS Code API semantics);
• test a >50-thread fixture where an old-created thread is newest by updatedAt.

The catalog freshness / useStateDbOnly observation remains a distinct secondary issue: it affects whether otherwise valid threads reach thread/list at all. It should not be conflated with the primary IDE adapter ordering/projection defect.

[Betafer]

Confirming this issue on:

• VS Code 1.131.0
• Codex extension 26.727.40816
• codex-cli 0.146.0-alpha.9.2
• macOS 26.6 arm64

The shipped extension still requests thread/list with:

{
  "limit": 50,
  "cursor": null,
  "sortKey": "created_at",
  "archived": false,
  "useStateDbOnly": true
}

The local state database contains 477 active VS Code threads. Comparing the first 50 threads ordered by created_at with the first 50 ordered by recency_at produces only 42 matches. Therefore, 8 genuinely recent conversations are omitted from or displaced in the visible “recent” set.

An older conversation resumed today does not move to the top because the provider truncates by creation time before VS Code can sort the returned items.

Please request recency_at or updated_at, expose the corresponding activity timestamp, and support cursor pagination. This also appears related to #36156, since a stale one-time fetch can compound the ordering/truncation problem.