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

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.

1. 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.

1. 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.

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.

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.