codex - 💡(How to fix) Fix VS Code extension session sidebar should match Codex CLI resume picker semantics [3 comments, 2 participants]

Summary

The VS Code extension session sidebar/task history currently behaves like a small recent-task teaser instead of an operational local session picker. In heavy local Codex usage this makes existing sessions hard to resume even when the same sessions are available through Codex CLI.

I think the sidebar should match the semantics of the Codex CLI resume picker, not necessarily its table layout.

Current behavior observed locally

On extension build:

openai.chatgpt-26.5422.30944-linux-x64

I observed the sidebar opening with a tiny visible subset such as a few rows plus a large View all (...) count. Earlier local hotpatches that increased page sizes made more sessions visible, but they either preserved a hidden cap or made first render slow when routed through full traversal.

Current relevant compiled locations in this build:

• Manager bundle: /root/.vscode-server/extensions/openai.chatgpt-26.5422.30944-linux-x64/webview/assets/app-server-manager-signals-DaIWbgQQ.js
  • refetchThreadList(...)
  • loadNextThreadListPage(...)
  • refreshRecentConversations(...)
  • loadMoreRecentConversations(...)
• UI bundle: /root/.vscode-server/extensions/openai.chatgpt-26.5422.30944-linux-x64/webview/assets/index-CrsC77dA.js
  • inline cap: slice(0,Math.max(3,e.length))
  • count label: View all ({total}) with values:{total:n.length}
  • task-history search filters loaded client-side arrays

CLI reference semantics

The current Codex CLI resume picker appears to use a better model:

• /home/tools/codex/codex-rs/tui/src/resume_picker.rs
  • PAGE_SIZE = 25
  • LOAD_NEAR_THRESHOLD = 5
  • background page loader
  • progressive search
  • default sort by UpdatedAt
• /home/tools/codex/codex-rs/app-server/src/codex_message_processor.rs
  • default thread-list limit is 25
  • individual server pages are bounded
• /home/tools/codex/codex-rs/app-server-protocol/src/protocol/v2.rs
  • ThreadListResponse currently has data, nextCursor, and backwardsCursor
  • it does not expose an exact same-filter total count

Desired behavior

On opening the VS Code extension/sidebar:

1. Show about 25 local/recent session rows immediately, not just a tiny teaser.
2. Sort by last updated time descending by default.
3. Expose both session creation time and last updated time in a compact sidebar-appropriate form.
4. Notify/render after the first page, then continue cursor pagination in bounded background/on-demand pages.
5. Keep UI responsive; do not block first local render on full traversal of all historical sessions.
6. Make the count label semantically honest:
   • distinguish visible rows vs loaded rows vs exact total;
   • if exact total is unavailable, say loaded/loaded+ rather than implying all rows are loaded.
7. Search should work beyond only the currently rendered rows, via backend searchTerm or progressive search/loading similar to CLI.

Local validation / experiment

I tested a local runtime hotpatch with the following semantics:

Manager bundle:

refetchThreadList: first page -> limit:25
loadNextThreadListPage: follow-up pages -> limit:100
refreshRecentConversations: notify after first page, then start bounded background cursor loading
loadMoreRecentConversations: serialize concurrent load-more calls to avoid cursor races

UI bundle:

slice(0,Math.max(3,e.length))
-> slice(0,Math.max(25,e.length))

View all ({total})
-> View all ({visible} / {loaded} loaded)

Local inline session rows were also patched to expose both timings compactly:

C <created relative time> · U <updated relative time>

Verification performed:

node --check app-server-manager-signals-DaIWbgQQ.js
node --check index-CrsC77dA.js

Both syntax checks passed, and static patch needles for first-page 25, next-page 100, background loader, serialized load-more guard, inline cap 25, loaded counter, and created/updated timing were present.

Why this matters

For users with hundreds or thousands of local Codex sessions, the VS Code extension needs to be a real resume/search surface. A tiny visible subset plus a misleading count makes session recovery unreliable, while synchronous full traversal can make the UI appear empty or cloud-only for too long.

The CLI already has a good model: small first page, updated-time sort, cursor loading, and progressive search. The extension should share those semantics.

Related

This is related to, but broader than, the hidden-cap/history issue:

• #15368

That issue is about sessions being hidden/truncated. This issue frames the desired fix as CLI-aligned session picker semantics for the VS Code extension/sidebar.