Activity

1. iqdoctor

   added

   extensionIssues related to the VS Code extensionIssues related to the VS Code extension

   on Mar 21, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   on Mar 21, 2026
3. github-actions commented on Mar 21, 2026

   

   github-actionsbot

   on Mar 21, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Sidebar only shows the 50 most recent threads, making older threads inaccessible #15060
   • Desktop app sidebar only shows loaded recent subset, not full workspace history #14751
   • VS Code extension loses thread history after restart on Linux even though auth session is restored #14812
   • Codex Desktop App does not display existing local sessions from shared CODEX_HOME #14389

   Powered by Codex Action
4. etraut-openai

   changed the title [-]Codex VS Code Plugin: Session list is capped too aggressively, Lost titles without disk fallback[/-] [+]Increase cap of sessions in VS Code extension[/+] on Mar 21, 2026
5. etraut-openai

   added

   enhancementNew feature or requestNew feature or request

   and removed

   bugSomething isn't workingSomething isn't working

   on Mar 21, 2026
6. iqdoctor commented on Mar 21, 2026

   

   iqdoctor

   on Mar 21, 2026

   Author

   More actions

   Added focused follow-up comments to two related issues:

   • issue #14812, comment: VS Code extension loses thread history after restart on Linux even though auth session is restored #14812 (comment)
   • issue #15060, comment: Sidebar only shows the 50 most recent threads, making older threads inaccessible #15060 (comment)

   Why this may help a coding agent process the duplicates better:

   • it gives a concrete constant and exact functions to inspect for the fix point
   • it separates a client-side visible cap from a deeper pagination / hydration boundary
   • it adds a validated local experiment, which narrows the search space
   • it turns the report from a generic UX complaint into a traced engineering bug

   What I intentionally did not do:

   • I did not comment on #14389, because it is already closed
   • I did not paste the same long note into every potential duplicate, to avoid diluting the signal

   👍React with 👍2Reacted by diogopereira1990 and lechuhuuha
7. iqdoctor commented on Mar 21, 2026

   

   iqdoctor

   on Mar 21, 2026

   Author

   More actions

   Codex VS Code Plugin Session Repair Notes

   Date: 2026-03-21

   Scope

   This note captures a repeatable workflow for debugging and hot-patching future Codex VS Code extension releases when:

   • the local session/thread list is silently truncated
   • sessions exist on disk but are missing or undiscoverable in the plugin because titles are blank

   This was validated on:

   • VS Code extension openai.chatgpt-26.5318.11754-linux-x64
   • bundled extension CLI codex-cli 0.116.0-alpha.10
   • system CLI /usr/bin/codex -> codex-cli 0.116.0
   • Linux remote VS Code server

   Symptoms Seen

   1. Hidden recent-thread cap

   Observed sequence:

   • plugin initially showed only 50 local sessions
   • after increasing the client page size, plugin showed 100
   • after forcing auto-pagination across nextCursor, plugin showed 313

   Conclusion:

   • there is a client-side recent-thread page size
   • there is also a deeper pagination boundary if the client does not continue loading

   2. Blank-title sessions

   Concrete example:

   • thread id 019ca226-b30c-7181-bdf0-62b891464a25
   • ~/.codex/session_index.jsonl still had thread_name = "Worker"
   • rollout file still existed on disk
   • but ~/.codex/state_5.sqlite had:
     • title = ''
     • first_user_message = ''

   Effect:

   • Codex CLI could still find the session as Worker
   • VS Code extension could not reliably surface it by name

   Primary Local Paths

   • extension bundle directory:
     • /root/.vscode-server/extensions/openai.chatgpt-*/webview/assets/
   • current runtime-patched bundle:
     • /root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js
   • current sourcemaps:
     • /root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js.map
     • /root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/index-BX_E-kXD.js.map
   • local Codex state:
     • /root/.codex/state_5.sqlite
     • /root/.codex/session_index.jsonl
     • /root/.codex/sessions/
     • /root/.codex/recovery/

   Root Cause Notes

   Recent-thread cap

   From the embedded sources in the sourcemap:

   • src/app-server/app-server-manager-constants.ts
     • RECENT_CONVERSATIONS_PAGE_SIZE = 50
   • src/app-server/app-server-manager.ts
     • refreshRecentConversations() requests thread/list with:
       • limit = RECENT_CONVERSATIONS_PAGE_SIZE * recentConversationsPageCount
     • loadMoreRecentConversations() requests thread/list with:
       • limit: RECENT_CONVERSATIONS_PAGE_SIZE
   • src/sidebar/sidebar-electron.tsx
     • sidebar uses useConversationsMeta()

   Interpretation:

   • UI is built from recent loaded conversations, not from the full on-disk session set
   • the extension does not automatically page through all local recent threads in this path

   Blank-title sessions

   From the embedded sources in the sourcemap:

   • src/app-server/app-server-manager.ts
     • upsertRecentConversationState() relies on:
       • thread.name
       • persisted title cache
     • it does not fall back to:
       • session_index.jsonl
       • rollout JSONL
       • recovery history
   • src/local-conversation/get-local-conversation-title.ts
     • fallback chain is:
       • conversationState.title
       • first turn input text
       • parent subagent prompt
     • no disk/index fallback

   Interpretation:

   • if recent-thread metadata loses title, the plugin can fail to surface a session by name even when disk data still exists

   How To Inspect New Releases

   1. Find the current hashed asset names

   find /root/.vscode-server/extensions/openai.chatgpt-* -type f | rg 'app-server-manager-hooks|index-.*\\.js\\.map|index-.*\\.js$'

   2. Check the embedded source map for the hardcoded page size

   python - <<'PY'
   import json
   p='/root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js.map'
   with open(p) as f: m=json.load(f)
   i=m['sources'].index('../../src/app-server/app-server-manager-constants.ts')
   print(m['sourcesContent'][i])
   PY

   Look for:

   • RECENT_CONVERSATIONS_PAGE_SIZE = 50

   3. Check the live compiled JS bundle for patch needles

   node - <<'NODE'
   const fs=require('fs');
   const p='/root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js';
   const s=fs.readFileSync(p,'utf8');
   for (const needle of [
     'let t=50*this.recentConversationsPageCount',
     '{limit:50,cursor:this.recentConversationsNextCursor',
     's.length>0&&(this.recentConversationIds=[...s,...this.recentConversationIds]),this.notifyAnyConversationCallbacks()}async hydratePinnedThreads'
   ]) {
     const idx=s.indexOf(needle);
     console.log('needle', needle, 'idx', idx);
   }
   NODE

   Quick Hot Patch For Future Versions

   A. Raise the recent-thread page size to 500

   Use the actual current hashed bundle path.

   node - <<'NODE'
   const fs=require('fs');
   const p='/root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js';
   let s=fs.readFileSync(p,'utf8');
   const before1='let t=50*this.recentConversationsPageCount';
   const after1='let t=500*this.recentConversationsPageCount';
   const before2='{limit:50,cursor:this.recentConversationsNextCursor';
   const after2='{limit:500,cursor:this.recentConversationsNextCursor';
   if (!s.includes(before1)) throw new Error('missing before1');
   if (!s.includes(before2)) throw new Error('missing before2');
   fs.copyFileSync(p, p + '.bak-quickhack');
   s=s.replace(before1, after1).replace(before2, after2);
   fs.writeFileSync(p, s);
   console.log('patched', p);
   NODE

   B. Force auto-pagination until 500 items or no nextCursor

   This is what was needed after the simple 50 -> 500 patch still only surfaced 100.

   node - <<'NODE'
   const fs=require('fs');
   const p='/root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js';
   let s=fs.readFileSync(p,'utf8');
   const before='s.length>0&&(this.recentConversationIds=[...s,...this.recentConversationIds]),this.notifyAnyConversationCallbacks()}async hydratePinnedThreads';
   const after='s.length>0&&(this.recentConversationIds=[...s,...this.recentConversationIds]);for(;this.recentConversationsNextCursor!=null&&this.recentConversationIds.length<500;)await this.loadMoreRecentConversations();this.notifyAnyConversationCallbacks()}async hydratePinnedThreads';
   if (!s.includes(before)) throw new Error('missing refresh tail');
   s=s.replace(before, after);
   fs.writeFileSync(p, s);
   console.log('patched refresh tail for auto-pagination');
   NODE

   C. Syntax check

   node --check /root/.vscode-server/extensions/openai.chatgpt-26.5318.11754-linux-x64/webview/assets/app-server-manager-hooks-DC8Cu72L.js

   D. Reload VS Code

   In VS Code:

   • Developer: Reload Window

   Blank Title Repair

   Goal

   Repair threads.title in state_5.sqlite from disk-backed sources:

   1. session_index.jsonl
   2. rollout JSONL
   3. recovery history.jsonl

   One-off repair script

   python - <<'PY'
   import sqlite3, json, shutil, re
   from pathlib import Path
   from datetime import datetime
   
   STATE = Path('/root/.codex/state_5.sqlite')
   BACKUP = Path(f'/root/.codex/state_5.sqlite.bak-{datetime.now().strftime("%Y%m%d-%H%M%S")}')
   IDX = Path('/root/.codex/session_index.jsonl')
   
   shutil.copy2(STATE, BACKUP)
   print('backup', BACKUP)
   
   idx_titles = {}
   if IDX.exists():
       with IDX.open() as f:
           for line in f:
               line=line.strip()
               if not line:
                   continue
               try:
                   obj = json.loads(line)
               except Exception:
                   continue
               tid = obj.get('id')
               title = (obj.get('thread_name') or '').strip()
               if tid and title:
                   idx_titles[tid] = title
   
   md_link_re = re.compile(r'\[([^\]]+)\]\([^)]+\)')
   
   def normalize_title(text: str) -> str:
       if not text:
           return ''
       text = md_link_re.sub(r'\1', text)
       text = re.sub(r'\s+', ' ', text).strip()
       if not text:
           return ''
       return text if len(text) <= 80 else text[:79].rstrip() + '…'
   
   def title_from_rollout(path: Path) -> str:
       if not path.exists():
           return ''
       try:
           with path.open() as f:
               for line in f:
                   try:
                       obj = json.loads(line)
                   except Exception:
                       continue
                   if obj.get('type') == 'event_msg' and obj.get('payload', {}).get('type') == 'user_message':
                       title = normalize_title(obj.get('payload', {}).get('message', ''))
                       if title:
                           return title
                   if obj.get('type') == 'response_item':
                       payload = obj.get('payload', {})
                       if payload.get('type') == 'message' and payload.get('role') == 'user':
                           texts = []
                           for part in payload.get('content') or []:
                               if isinstance(part, dict) and 'text' in part:
                                   texts.append(part.get('text', ''))
                           title = normalize_title(' '.join(texts))
                           if title:
                               return title
       except Exception:
           return ''
       return ''
   
   def title_from_recovery(tid: str) -> str:
       p = Path(f'/root/.codex/recovery/{tid}/history.jsonl')
       if not p.exists():
           return ''
       try:
           with p.open() as f:
               for line in f:
                   try:
                       obj = json.loads(line)
                   except Exception:
                       continue
                   title = normalize_title(obj.get('text', ''))
                   if title:
                       return title
       except Exception:
           return ''
       return ''
   
   conn = sqlite3.connect(STATE)
   cur = conn.cursor()
   cur.execute("select id, rollout_path from threads where title='' or title is null")
   rows = cur.fetchall()
   
   for tid, rollout_path in rows:
       title = idx_titles.get(tid, '')
       if not title and rollout_path:
           title = title_from_rollout(Path(rollout_path))
       if not title:
           title = title_from_recovery(tid)
       if title:
           cur.execute(
               "update threads set title=?, first_user_message=coalesce(nullif(first_user_message,''), ?) where id=?",
               (title, title, tid),
           )
   
   conn.commit()
   cur.execute("select count(*) from threads where title='' or title is null")
   print('blank_remaining', cur.fetchone()[0])
   PY

   Validation Commands

   Count blank titles

   sqlite3 /root/.codex/state_5.sqlite "select count(*) from threads where title='' or title is null;"

   Inspect a specific thread

   sqlite3 /root/.codex/state_5.sqlite "select id,title,first_user_message,cwd,source from threads where id='019ca226-b30c-7181-bdf0-62b891464a25';"
   rg -n '019ca226-b30c-7181-bdf0-62b891464a25' /root/.codex/session_index.jsonl

   Check how many repaired titles still look bad

   sqlite3 /root/.codex/state_5.sqlite "select count(*) from threads where title like '# AGENTS.md instructions%';"

   Notes

   • The quick repair filled blank titles fast, but some reconstructed titles may still be noisy if the only available on-disk source is a wrapped prompt payload.
   • A proper upstream fix should do read-repair in the metadata layer, not in the UI row renderer.
   • Extension updates will overwrite the patched webview bundle, so future versions need the same inspection + reapplication flow.

   Related GitHub Issues

   • head issue:
     • https://github.com/openai/codex/issues/15368
   • related comments added:
     • https://github.com/openai/codex/issues/14812#issuecomment-4102065616
     • https://github.com/openai/codex/issues/15060#issuecomment-4102065633
     • https://github.com/openai/codex/issues/15368#issuecomment-4102425406
8. iqdoctor commented on Mar 22, 2026

   

   iqdoctor

   on Mar 22, 2026

   Author

   More actions

   Follow-up from 2026-03-22.

   The extension version was still unchanged on my machine:

   • openai.chatgpt-26.5318.11754-linux-x64

   I verified that the previous hot patches were still present in the active bundle:

   • 50 -> 500 page-size change in refreshRecentConversations()
   • 50 -> 500 page-size change in loadMoreRecentConversations()
   • auto-pagination loop over nextCursor

   Despite that, the visible local session count had dropped again, this time to 200 instead of the previously observed 313.

   That suggests the issue is deeper than just RECENT_CONVERSATIONS_PAGE_SIZE = 50. The more reliable workaround was to bypass the initial recent-page request entirely and make refreshRecentConversations() use the existing full traversal path:

   • listAllThreads({ modelProviders: null, archived: false })

   So the refined diagnosis is:

   • there is a visible client-side recent-page cap,
   • but there is also a deeper instability/boundary in the thread/list recent-loading path,
   • and listAllThreads() is currently a stronger workaround than only raising the page size and chasing nextCursor.
9. iqdoctor commented on Mar 29, 2026

   

   iqdoctor

   on Mar 29, 2026

   Author

   More actions

   Follow-up: after another VS Code extension auto-update, I re-applied the same local runtime patch to the new bundle and the full thread list became visible again.

   Current extension version:

   • 26.5325.31654

   Patched bundle:

   • /root/.vscode-server/extensions/openai.chatgpt-26.5325.31654-linux-x64/webview/assets/app-server-manager-hooks-XL0eRatK.js

   Local workaround re-applied:

   • refreshRecentConversations() switched from the initial thread/list page to listAllThreads({ modelProviders: null, archived: false })
   • loadMoreRecentConversations() raised from 50 to 500

   Observed result after Developer: Reload Window:

   • the sidebar now shows 414 sessions again

   This is another data point that the store update simply overwrites the patched webview bundle, and that the underlying issue is still the same recent-thread loading path rather than missing local session data.

   ❤️React with ❤️3Reacted by lechuhuuha, Tom Spis and Łukasz Kowalski
10. iqdoctor commented on Apr 17, 2026

    

    iqdoctor

    on Apr 17, 2026

    Author

    More actions

    Follow-up: in a newer VS Code extension build, the underlying issue is still reproducible, but the recent-thread loading logic has moved to a different compiled asset/module.

    Current extension version:

    • 26.5415.20818

    Relevant asset now:

    • /root/.vscode-server/extensions/openai.chatgpt-26.5415.20818-linux-x64/webview/assets/app-server-manager-signals-Dcn6qX09.js

    In older builds, the patch point was in app-server-manager-hooks-*.
    In this build, the relevant patch points moved to the delegated recent-thread loader methods:

    • refetchThreadList(...)
    • loadNextThreadListPage(...)

    Local workaround re-applied successfully:

    • refetchThreadList(...) switched from the initial listRecentThreads({ limit: 50 * this.pageCount, cursor: null }) path to a full traversal through listAllThreadsRequest (lv(...) in the compiled bundle)
    • loadNextThreadListPage(...) raised from 50 to 500

    This looks like the same product bug, but it is useful to note that the implementation moved. That makes the regression easy to carry forward across releases even when the symptom stays identical.
11. iqdoctor commented on Apr 21, 2026

    

    iqdoctor

    on Apr 21, 2026

    Author

    More actions

    Follow-up after another VS Code extension update: same symptom and same conceptual workaround, but the compiled asset/module moved again.

    Current extension version:

    • 26.5417.40842

    Relevant asset now:

    • /root/.vscode-server/extensions/openai.chatgpt-26.5417.40842-linux-x64/webview/assets/send-app-server-request-C98EYioR.js

    Previously the recent-thread loader had moved to app-server-manager-signals-*; in this build it is now bundled under send-app-server-request-*.

    The conceptual patch points are still the same:

    • refetchThreadList(...)
    • loadNextThreadListPage(...)

    Local workaround re-applied successfully:

    • initial refresh now uses the full traversal helper (mv(...) in this minified bundle, corresponding to listAllThreadsRequest)
    • load-more page size raised from 50 to 500

    So the underlying bug appears unchanged, but the implementation keeps moving between compiled assets. This is useful for any coding agent working on the issue because searching only the old bundle names will miss the current patch point.
12. thephotocrv commented on Apr 24, 2026

    

    thephotocrv

    on Apr 24, 2026

    More actions

    I am seeing the same issue on macOS with Codex Desktop 26.422.21637 (CFBundleVersion 2056).

    The important part: local data is not missing. The threads exist in ~/.codex/state_5.sqlite, but Codex Desktop only loads a global window of recent threads and then projects appear incomplete or as if they had no chats.

    Current local evidence:

    • ~/.codex/state_5.sqlite has the expected project threads:
      • Crv_PM: 14 active threads
      • WebPhotoCRV: 8 active threads
      • AyudaCodex: 5 active threads
    • ~/.codex/.codex-global-state.json is not empty:
      • active_roots: 3
      • thread_titles: 27
      • thread_order: 27
    • ~/.codex/session_index.jsonl: 27 entries
    • Codex telemetry in ~/Library/Application Support/Codex/sentry/scope_v3.json repeatedly reports:
      • thread_count_total: 50
      • thread_count_loaded_recent: 50

    I also inspected /Applications/Codex.app/Contents/Resources/app.asar and found the recent thread loader starts with:

    pageCount=1
    refetchThreadList(...) -> limit: 50 * this.pageCount
    loadNextThreadListPage(...) -> limit: 50

    This matches the observed behavior: if a workspace/project has threads outside the initial global recent window, the Desktop UI does not show the complete project even though the local SQLite data is present.

    I tried the usual safe steps:

    • reinstalling Codex.app
    • clearing app cache / local app support
    • checking global-state and session_index
    • reorganizing project folders

    None of those fixed the issue because the underlying thread data was already present.

    Expected behavior:

    • When expanding a project/workspace, Desktop should fetch/list threads for that specific cwd/workspace, not only rely on the initial global recent-thread window.
    • Alternatively, RECENT_CONVERSATIONS_PAGE_SIZE should be configurable or much larger.
    • By project should not show incomplete projects just because their threads fell outside the initial recent window.

    This is a serious workflow blocker for projects with more than a handful of threads.

    👍React with 👍1Reacted by Valeriy Pavlovich
13. thephotocrv commented on Apr 24, 2026

    

    thephotocrv

    on Apr 24, 2026

    More actions

    Additional local finding after deeper testing. This may help isolate the actual Desktop reindexing bug:
    the issue is not only the 50 global recent-thread limit. There is also a reindexing/source-of-truth mismatch.

    Root cause observed locally:

    Codex Desktop does not reliably render project thread visibility from state_5.sqlite or session_index.jsonl alone. The UI state appears to be derived from the mtime of the rollout-*.jsonl files under:

    ~/.codex/sessions/
    combined with the global recent-conversations preload limit of 50.
    
    Concrete reproduction:
    
    I had a project with 14 active threads in state_5.sqlite.
    All 14 had the same exact cwd.
    None were archived.
    git_branch, git_sha, and worktree-related fields were not different.
    Updating only state_5.sqlite updated_at / updated_at_ms did not make the hidden threads appear in Codex Desktop.
    Updating session_index.jsonl and .codex-global-state.json also did not make them appear.
    Codex Desktop reverted/recomputed the SQLite updated_at values on launch.
    The values it restored matched the filesystem modification times of the corresponding rollout-*.jsonl files.
    After updating both:
    SQLite updated_at / updated_at_ms
    the mtime of each corresponding rollout-*.jsonl
    The project immediately showed all 14 threads in the UI.
    So the effective UI source of truth seems to be:
    
    rollout-*.jsonl mtime -> reindex -> SQLite/session index -> UI
    or at least the rollout file mtime participates in reindexing strongly enough to override manual SQLite/index changes.
    
    This explains why users see projects with missing threads even when local data exists and SQLite counts are correct.
    
    Expected behavior:
    
    Project thread lists should be resolved by project/workspace cwd, not only by a global recent window.
    The UI should not report a project as empty or partially empty when valid local threads exist for that exact cwd.
    Reindexing should use a stable thread metadata source, not filesystem mtime as a hidden effective source of truth.
    If mtime is intentionally used, it should be documented and kept consistent with SQLite/session metadata.
    Requested fix:
    
    Increase the global recent conversations preload from 50 to at least 200.
    Ideally make it configurable, e.g. in ~/.codex/config.toml:
    recent_conversations_page_size = 200
    or allow an unlimited / “load all local project threads” mode.
    
    Even better:
    
    When expanding a project, query local threads by cwd / project root directly.
    Do not depend on whether those threads happen to be in the latest 50 global recent conversations.
    Add proper pagination/search for local project threads.
    Make “By project” actually load all local threads for that project.
    Current workaround:
    
    I created a local script that, with Codex Desktop closed:
    
    backs up state_5.sqlite
    backs up .codex-global-state.json
    backs up session_index.jsonl
    backs up the affected rollout-*.jsonl
    updates SQLite updated_at
    updates the corresponding rollout file mtime
    rebuilds session_index.jsonl
    limits visible projects to the active project plus a helper project
    After doing this, the project becomes visible again in Codex Desktop.
    
    This is not a real fix. It is only a workaround to force Codex Desktop to reindex hidden local threads.
    
    Please fix this in Desktop. A hardcoded global recent-thread window of 50 is far too low for real Codex usage, because many users create many threads due to context limits, not because they want fragmented project history.
    

    👍React with 👍1Reacted by Valeriy Pavlovich
14. iqdoctor commented on Apr 24, 2026

    

    iqdoctor

    on Apr 24, 2026

    Author

    More actions

    Follow-up after another VS Code extension update: same symptom and same conceptual workaround, but the compiled asset/helper moved again.

    Current extension version:

    • 26.5422.21459

    Relevant asset now:

    • /root/.vscode-server/extensions/openai.chatgpt-26.5422.21459-linux-x64/webview/assets/app-server-manager-signals-DaIWbgQQ.js

    In the previous reapply, the relevant logic had moved under send-app-server-request-*.
    In this build, the active patch target is back under app-server-manager-signals-*.

    The conceptual patch points are still the same:

    • refetchThreadList(...)
    • loadNextThreadListPage(...)

    Local workaround re-applied successfully:

    • initial refresh switched from listRecentThreads({ limit: 50 * this.pageCount, cursor: null }) to the full traversal helper (ey(...) in this minified bundle)
    • load-more page size raised from 50 to 500

    So the underlying bug still appears unchanged, but the implementation keeps moving between compiled assets and helper names (lv(...) -> mv(...) -> ey(...)). That makes the regression easy to carry forward across releases, and it means searching only older bundle names will miss the current patch point.
15. thephotocrv commented on Apr 24, 2026

    

    thephotocrv

    on Apr 24, 2026

    More actions

    Additional external confirmation: after another update, the same bug remains but the compiled patch target moved again.

    In extension version 26.5422.21459, the relevant logic moved to:

    webview/assets/app-server-manager-signals-DaIWbgQQ.js

    The conceptual patch points are still:

    • refetchThreadList(...)
    • loadNextThreadListPage(...)
    • global recent thread list limit around 50

    A local workaround reportedly changed the initial refresh from:

    listRecentThreads({ limit: 50 * this.pageCount, cursor: null })

    to a full traversal helper, and raised load-more page size from 50 to 500.

    This reinforces that the underlying bug is unchanged, but the compiled implementation keeps moving between builds. A local bundle patch is therefore not a maintainable solution.

    Please expose an official setting or fix project thread loading so project views query all local threads by project/cwd instead of depending on the latest 50 global recent threads.

    👍React with 👍1Reacted by Valeriy Pavlovich
16. iqdoctor commented on Apr 25, 2026

    

    iqdoctor

    on Apr 25, 2026

    Author

    More actions

    Follow-up after another VS Code extension auto-update: the regression happened again, but this time the compiled asset/helper did not move.

    Current extension version:

    • 26.5422.30944

    Relevant asset:

    • /root/.vscode-server/extensions/openai.chatgpt-26.5422.30944-linux-x64/webview/assets/app-server-manager-signals-DaIWbgQQ.js

    Compared with 26.5422.21459:

    • asset family/name stayed the same: app-server-manager-signals-DaIWbgQQ.js
    • patch points stayed the same: refetchThreadList(...) and loadNextThreadListPage(...)
    • full traversal helper stayed the same: ey(...)

    But the store update still restored the original recent-thread behavior:

    • initial refresh was back to listRecentThreads({ limit: 50 * this.pageCount, cursor: null })
    • load-more was back to limit: 50

    Local workaround re-applied successfully:

    • initial refresh now uses full traversal through ey(...)
    • load-more page size raised from 50 to 500
    • node --check passes for the patched bundle

    This adds a slightly different data point: the bug/regression is not only caused by implementation moving between compiled assets. Even when the asset and helper remain stable across builds, the extension update overwrites the runtime bundle and brings back the hidden recent-thread cap.
17. iqdoctor commented on Apr 25, 2026

    

    iqdoctor

    on Apr 25, 2026

    Author

    More actions

    Follow-up from the latest local validation on openai.chatgpt-26.5422.30944-linux-x64:

    The issue is not only the visible client-side cap. A naive local workaround that replaces the first refetchThreadList(...) page with the existing recursive full traversal helper (ey(...), internally paging thread/list at limit:200) can make startup worse for large local histories.

    Observed locally:

    • ~/.codex/state_5.sqlite has 1963 rows in threads.
    • Forcing initial refetchThreadList(...) through full recursive traversal caused the VS Code UI to stay cloud-only while local sessions were still being walked/hydrated.
    • A less blocking workaround was to use a larger first page and preserve cursor-based pagination:
      • refetchThreadList(...): listRecentThreads({ limit: 500 * this.pageCount, cursor: null }), then keep nextCursor = r.nextCursor
      • loadNextThreadListPage(...): limit:500

    Why this may help triage:

    • There are two separate boundaries: the current small initial/list page cap, and the deeper pagination/full-hydration behavior.
    • A robust fix probably needs incremental rendering/pagination rather than synchronously loading all local threads before the first local list notify.
    • The relevant current compiled symbols in this build remained refetchThreadList(...), loadNextThreadListPage(...), and helper ey(...) in app-server-manager-signals-DaIWbgQQ.js.
18. iqdoctor commented on Apr 25, 2026

    

    iqdoctor

    on Apr 25, 2026

    Author

    More actions

    Follow-up: I opened a separate issue for the broader VS Code sidebar semantics that this cap/history bug exposed:

    • VS Code extension session sidebar should match Codex CLI resume picker semantics #19603

    Why this may be useful for agent triage:

    • it separates the hidden cap symptom from the desired CLI-like loading semantics;
    • it points to concrete current fix points in the installed extension build (refetchThreadList, loadNextThreadListPage, refreshRecentConversations, inline slice(0,Math.max(3,e.length)), and the View all ({total}) label);
    • it references the Codex CLI resume picker model (PAGE_SIZE = 25, updated-time sort, cursor/background loading, progressive search);
    • it calls out a protocol boundary: current ThreadListResponse has cursors but no exact same-filter total, so the UI should not present loaded rows as if they are total rows.

    I intentionally kept this as a cross-reference rather than duplicating the full spec into this thread, so #15368 can remain focused on the disappeared/truncated history symptom.
19. interconnectedMe commented on Jul 8, 2026

    

    interconnectedMe

    on Jul 8, 2026

    More actions

    Truncation also a problem for me on long-running chat sessions with multiple compactions.

    Codex (gpt-5.5) tells me that it's an issue with VScode not handling either the compactions, or just the length of some of the chats.

    If I know what the last thing I saw was, or roughly where we were, Codex can find the session that is truncated and then I can read or Codex can summarize to pick up where we were.

    But can cause a little disorientation while I try to work out what's happened.
20. gerashegalov commented on Jul 9, 2026

    

    gerashegalov

    on Jul 9, 2026

    More actions

    Confirmed on VS Code extension 26.5623.141536-linux-x64.

    The webview sidebar now has paginated/full-traversal paths, but the native VS Code chat-session provider remains capped. provideChatSessionItems() calls requestThreadList() once with:

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

    It maps only that response's data and never follows nextCursor. The provider is registered through vscode.chat.registerChatSessionItemProvider("openai-codex", ...).

    Expected: follow nextCursor incrementally, or implement load-more/progressive search. Sorting by updated_at would also better represent "recent chats".

    This appears to be a remaining extension-host code path after the sidebar pagination improvements, rather than an app-server storage limitation.
21. cixiangtao commented on Aug 17, 2026

    

    cixiangtao

    on Aug 17, 2026

    More actions

    There is now a complementary unofficial, temporary workaround for users whose current-project sessions are crowded out by unrelated projects in the global VS Code Recent Tasks query:

    https://github.com/cixiangtao/codex-vscode-project-patch

    npx -y codex-vscode-project-patch

    Instead of increasing the global page size, this tool patches the Webview-originated thread/list bridge to include the active vscode.workspace.workspaceFolders paths as cwd. The app-server then returns the page for the current workspace roots, so unrelated repositories no longer consume the Webview task-list result window.

    This distinction is important:

    • It does not remove or increase the hard page cap.
    • It does not implement cursor pagination, progressive search, or blank-title recovery.
    • It intentionally does not patch the native vscode.chat.registerChatSessionItemProvider path described above; that provider can remain capped independently.
    • It only improves the Webview Recent Tasks case where global cross-project results make a bounded list less useful.

    The CLI is version/hash gated, creates and verifies an original-file backup, validates the patched JavaScript, and refuses unknown bundle layouts. Restore is:

    npx -y codex-vscode-project-patch restore

    It modifies the installed extension locally and does not redistribute the official VSIX. Extension updates normally replace the patch. This should be treated as a narrow stopgap while the upstream extension adds proper project-scoped loading plus cursor-based pagination across all history providers.
22. evandrocoan commented on Sep 23, 2026

    

    evandrocoan

    on Sep 23, 2026

    More actions

    I reproduced this with Codex VS Code extension 26.917.61114 on Linux. An older conversation was still present locally but did not appear in VS Code because it fell beyond the 50 most recent conversations.

    Increasing the fetch limit alone was insufficient: the extension also truncated the fetched results with e.slice(0,50) before passing them to the history UI.

    I made a temporary workaround that raises the local history limit to 199, uses the extension’s existing pagination, and removes that second truncation for local conversations. After “Developer: Reload Window”, the missing conversation appeared.

    The patcher, test, and instructions are pinned to this commit:
    evandrocoan/dotfiles@bcae1e3

    The test covers the 199-conversation boundary and catches the original 50-result truncation. This patches the installed extension bundle, so an extension update can overwrite it. The patcher rejects bundle layouts it does not recognize; it should be reviewed and adapted for new extension versions rather than applied blindly.