Codex Desktop: recent local project threads are missing from sidebar/search although session_index and read_thread can load them #30385

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on Jun 27, 2026
2. github-actions commented on Jun 27, 2026

   

   github-actionsbot

   on Jun 27, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Desktop 26.616.51431 - Project/Workspace Chats Missing from Sidebar After Update #29337
   • Codex Mac sidebar hides existing unpinned threads after update #29550
   • Codex update unexpectedly archives or hides recent local threads #30163
   • Codex Desktop appends new turns to wrong existing thread after update/restart; sidebar/catalog stale #30245
   • Codex Desktop Windows: chats created from a saved project still show as “No chats” under that project #29366

   Powered by Codex Action
3. szechner commented on Jun 27, 2026

   

   szechner

   on Jun 27, 2026

   Author

   More actions

   Additional observation: around the same time, ChatGPT iOS app / Codex mobile also failed to load conversation contents for the same account, while ChatGPT web continued to work. This may be a separate client-side/mobile loading issue, but it suggests the problem might not be limited to the desktop sidebar UI.
4. theodoreye001 commented on Jun 29, 2026

   

   theodoreye001

   on Jun 29, 2026

   More actions

   I’m seeing a very similar issue on Windows with Codex Desktop, but my case looks more severe than the original report.

   In my case, this is not only “recent local project threads are missing from sidebar/search while they can still be loaded directly”. I also see signs that the local sidebar catalog/migration is incomplete, and many historical session files appear to be missing from disk.

   Local evidence from my machine:

   • C:\Users\<user>\.codex\state_5.sqlite still contains 205 rows in the threads table
   • C:\Users\<user>\.codex\sqlite\codex-dev.db has local_thread_catalog = 0
   • local_thread_catalog_sync_state is ('local', NULL, 0, 19)
   • so initial_build_complete = 0
   • C:\Users\<user>\.codex\sessions only contains 4 rollout-*.jsonl files, and all of them are from 2026-06-29
   • C:\Users\<user>\.codex\archived_sessions contains 0 files

   I also checked the older metadata snapshots:

   • C:\Users\<user>\.codex\sqlite\state_5.sqlite still has 212 thread rows
   • but the newer sidebar/catalog DB did not reconstruct any visible local thread catalog entries

   So this seems related to the same general family of bugs discussed here, but with an extra failure mode:

   1. sidebar/search/catalog does not show local threads
   2. catalog build looks incomplete
   3. a large number of historical rollout-*.jsonl files are no longer present in the expected session directories

   From the user perspective, the result is:

   • project groups still appear
   • each group says “No conversations”
   • Archived Conversations is empty
   • only very recent/new threads remain visible

   This has reportedly happened repeatedly after Codex updates on the same Windows machine.

   If helpful, I can provide more exact local state details privately, but I wanted to confirm that this is not just a one-off missing-sidebar-entry case. It may be a broader Windows migration/indexing/storage issue affecting local thread recovery.

   This feels worse than a pure UI indexing bug, because in my case the historical session files themselves also appear to be missing.
5. branmckeown commented on Jul 6, 2026

   

   branmckeown

   on Jul 6, 2026 – with ChatGPT Codex Connector

   More actions

   Adding another Windows Codex Desktop data point that matches this issue.

   Observed on 2026-07-05 after shutting down/restarting the computer:

   • A project-backed thread that had previously been visible in Codex Desktop disappeared from the normal sidebar/search after restart.
   • Searching for the exact topical term in the thread title, including Visibility, did not surface the thread. list_threads(query="Visibility") returned only the active troubleshooting thread, not the missing project thread.
   • The thread was not deleted: local Codex state still referenced the thread ID, and read_thread by the recovered ID loaded it successfully.
   • Direct read showed the missing thread had status.type = "notLoaded", an empty preview, and belonged to the expected project workspace.
   • Pinning the recovered thread by ID succeeded, which made it visible again.

   Expected behavior: a local project thread that still exists and whose title matches the search query should appear in Codex Desktop sidebar/search after restart, or the app should repair/reindex local thread metadata automatically.

   Actual behavior: the thread was recoverable only by inspecting local Codex state and using the direct thread ID.

   I am intentionally omitting the specific local path and thread ID from this public comment, but this was reproducible enough to make the user think the agent chat had been deleted.
6. quantuan125 commented on Jul 6, 2026

   

   quantuan125

   on Jul 6, 2026

   More actions

   Any update on this? Experiencing similar issue
7. Northern-Summer commented on Jul 6, 2026

   

   Northern-Summer

   on Jul 6, 2026

   More actions

   I believe my newly filed issue #31259 is most likely a duplicate of this one, with one additional diagnostic clue that may help narrow the trigger condition.

   Additional observation from a separate Windows Codex Desktop case on 26.623.13972.0:

   • the missing thread could still be opened/read directly by thread ID
   • sidebar, thread list, and thread search all failed to surface it
   • rename/archive-style thread management paths also behaved as if the thread did not exist in the visible registry
   • the thread's local metadata appeared to have abnormally long title / preview values that looked like body content or a pasted first-user-message summary, rather than a short thread title

   That makes this look even more like a sidebar/list registration or hydration failure on top of existing local thread data, rather than data loss.

   Issue #30644 also looks closely related, because it reports stale or mismatched title/preview metadata on a live thread that is not visible in the sidebar. My current guess is that these reports are all part of the same bug family, with malformed or stale thread-summary metadata being one possible trigger.
8. joshmouch commented on Jul 22, 2026

   

   joshmouch

   on Jul 22, 2026

   More actions

   I can reproduce the same failure through the VS Code extension on macOS.

   Environment

   • VS Code 1.129.1 (arm64)
   • OpenAI Codex extension openai.chatgpt 26.5715.61943
   • Codex CLI 0.145.0

   The extension registers a VS Code chat-session item provider and requests the Codex app server with:

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

   Observed state:

   • ~/.codex/session_index.jsonl contains valid local sessions updated on 2026-07-20, including 019f8104-194c-74f1-8c4c-9cefe5bfc4d0 and 019f7fcb-d204-70e1-be7e-e39c0cd03172.
   • Those IDs are absent from ~/.codex/sqlite/codex-dev.db table local_thread_catalog.
   • The newest catalogued local threads are dated 2026-07-14.
   • As a result, VS Code Sessions cannot show the current conversations although the primary session index has them.

   This is not a VS Code filter issue. The state-only catalog is stale, and the IDE has no supported refresh or fallback path. A fix appears to require either reliable reconciliation of local_thread_catalog from the session index, or a safe thread/list fallback/refresh when the state-only catalog is stale.

   Related UX detail: the extension requests sortKey: "created_at" and uses the returned creation time for session timing, so an actively updated old session displays its original age rather than its most recent update.
9. joshmouch commented on Jul 22, 2026

   

   joshmouch

   on Jul 22, 2026

   More actions

   Correction / narrower root cause from inspecting the current VS Code provider:

   The primary list-ordering defect is not merely a stale-catalog fallback. The provider makes exactly this bounded request:

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

   It then maps only createdAt to the VS Code session item:

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

   So when VS Code is set to Updated, it can sort only among the provider's already-truncated 50 creation-ordered candidates; current sessions older than that creation cutoff are never returned to VS Code. The provider also does not supply a last-updated timestamp in its session item.

   The stale local_thread_catalog evidence still matters for sessions absent from the state-only catalog, but the created_at + limit: 50 request independently explains why an Updated sort does not reveal many older-but-recently-active sessions.

   Could a maintainer confirm the intended thread/list contract for IDE history? If the intended behavior is recent activity, I would like to contribute a focused PR, with tests, to request/update by updated_at and propagate the correct timing metadata (or implement the maintainer-preferred equivalent). I understand from CONTRIBUTING that an invitation is required before opening the PR.
10. joshmouch commented on Jul 22, 2026

    

    joshmouch

    on Jul 22, 2026

    More actions

    Scope correction: this issue is specifically about Codex Desktop, while my VS Code extension findings belong in a separate report. Please treat my earlier comments here only as related evidence about the shared thread/list / state-catalog behavior; I am filing the VS Code-specific report separately so the extension owner can triage it.
11. boombx403-byte commented on Aug 18, 2026

    

    boombx403-byte

    on Aug 18, 2026

    More actions

    Hi @szechner, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

    If you still have the affected local Codex directory, you can inspect it via:

    pip install codex-rescue==0.1.0a5
    codex-rescue sessions --json

    No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.
12. StreamVi commented on Aug 25, 2026

    

    StreamVi

    on Aug 25, 2026 – with ChatGPT Codex Connector

    More actions

    Recurrence: active Codex Desktop chat disappeared during a long-running turn (2026-08-26)

    This happened again on Windows while an active Codex Desktop thread was still doing multi-step tool work. The chat disappeared from the Desktop UI/sidebar before the task had finished, even though the agent turn/context continued.

    Environment

    • Codex Desktop on Windows
    • Workspace runtime: WSL2, Ubuntu 22.04.5 LTS
    • Kernel: 6.6.114.1-microsoft-standard-WSL2
    • Codex CLI available to the app/runtime: 0.130.0-alpha.5
    • Timezone: Europe/Moscow

    Observed

    • The currently active chat vanished from the Desktop UI/sidebar while work was in progress.
    • This is a recurrence; the same user has seen the chat disappear before.
    • The thread was long-running and its conversation context was compacted around the same period. That timing is only a correlation; I cannot confirm compaction as the cause.
    • The agent turn continued, so this does not look like an intentional delete action.
    • No repository/workspace data loss was observed.

    Expected

    The active thread should remain visible and selectable throughout a long-running turn. Context compaction, background tool activity, and sidebar/index refreshes must not remove its UI entry.

    It may be useful to inspect sidebar/thread-list invalidation and local catalog reconciliation around context compaction and long-running active turns, in addition to the stale-catalog cases already documented here.

    For privacy, I am omitting the thread ID, workspace/project paths, customer/production data, and tokens.
13. mmmd3d-source commented on Sep 3, 2026

    

    mmmd3d-source

    on Sep 3, 2026 – with ChatGPT Codex Connector

    More actions

    I can reproduce this issue family on Windows Codex Desktop with agent-created tasks, so the trigger does not appear to be limited to pasted-text attachment starts.

    For affected tasks:

    • rollout history remained intact;
    • project association and session-index data were present;
    • direct reads by task ID worked;
    • the tasks were nevertheless absent from normal project sidebar discovery.

    A reliable recovery was to send one ordinary direct user-role text message to the already-hidden task. After that message, the missing visibility metadata was populated and the task became visible again. No manual database edit was needed. We repeated this recovery across multiple affected tasks, and pilot tasks remained visible after full Desktop restarts.

    This corroborates the later-inline-follow-up observation in #35249 and may be relevant to the reserved-thread metadata staging work in #38819. It suggests that a later genuine user message triggers a metadata backfill/upsert path that the initial agent-created task path misses.

    It would be useful to apply the same backfill automatically during task creation or Desktop sidebar hydration for intact, unarchived tasks, rather than requiring a user message.
14. znbsf commented on Sep 4, 2026

    

    znbsf

    on Sep 4, 2026

    More actions

    Adding a current Windows data point for the agent-created worktree path.

    Environment

    • Codex Desktop: 26.901.2854.0
    • Active Desktop Codex core: 0.153.0
    • Windows 11 Pro, x64, build 26200
    • Observed: 2026-09-04

    Reproduction and observed state

    Two tasks were created through the Codex App create_thread tool for the same saved local Git project, each using its own Codex-managed worktree.

    Both creations progressed past the pending clientThreadId stage and produced canonical thread IDs. For both affected tasks:

    • the task is absent from the selected and expanded project sidebar;
    • list_threads(limit=50) does not return it;
    • the archived-task listing does not return it;
    • read_thread by canonical thread ID succeeds and reports status.type = "notLoaded";
    • direct navigation by canonical thread ID opens the intact task;
    • opening it directly does not make it reappear in the sidebar/list;
    • Desktop global state still contains the bidirectional client-new-thread to canonical-thread binding, the thread-to-project assignment, and the thread description;
    • the corresponding session JSONL and Git worktree still exist.

    The correct project was selected and expanded while reproducing this. No local Codex state files were edited.

    This appears to rule out, for this reproduction, a task that never materialized, an unresolved clientThreadId, accidental archiving, a missing project assignment, or loss of the rollout/worktree. The remaining failure looks like sidebar/list eligibility metadata not being populated or refreshed during the agent-created worktree path, or the Desktop catalog ignoring the already-persisted association. That is an inference, not a confirmed root cause.

    This aligns closely with the 2026-09-03 agent-created-task comment above. One additional distinction is that direct navigation alone does not repair visibility. I did not test the reported ordinary direct user-message recovery path, so I cannot confirm whether it backfills the missing metadata in this case.

    I also confirmed that the running 0.153.0 core contains the merged work from #38819, #38940, and #39523 by Git ancestry, so the symptom remains reproducible after those backend metadata/project/empty-preview changes.

    All task IDs, local paths, project names, prompts, account identifiers, and raw state contents are intentionally omitted.
15. dimasyankauskas commented on Sep 8, 2026

    

    dimasyankauskas

    on Sep 8, 2026

    More actions

    Adding a current macOS data point that closely matches the 2026-09-04 agent-created-task reproduction, but this case used the saved project checkout directly rather than a Codex worktree.

    Environment

    • ChatGPT desktop app: 26.901.51231, bundle 8109
    • macOS 27.0, build 26A5425a
    • Observed: 2026-09-07
    • Saved local Git project
    • Task created from another Codex chat through create_thread with environment type local

    Reproduction

    1. From an existing project chat, create a separate task targeting the same saved local project.
    2. create_thread returns a canonical thread ID and the new task begins substantial tool work.
    3. The target remains active and reaches a waiting-on-approval state. Direct read reports the expected project working directory.
    4. list_threads(limit=50) omits the target. The archived-thread list also omits it, and the expanded project sidebar has no entry.
    5. Direct navigation by canonical thread ID opens the intact task.
    6. Direct navigation alone does not register the task in the normal list.
    7. Pinning the task by canonical ID succeeds. After pinning, list_threads returns it in pinnedThreads and it becomes visible as a persistent sidebar entry.

    Sanitized local metadata

    Before the pin workaround, the legacy thread row showed:

    • archived = 0
    • has_user_event = 0
    • title length = 0
    • preview length = 0
    • current created/updated timestamps

    The local_thread_catalog row already existed and showed:

    • display title length = 37
    • missing_candidate = 0
    • pending_observed_title = 1
    • empty project_id
    • empty conversation_origin
    • correct project working directory

    No thread ID, project name/path, prompt, or account data is included here.

    Expected

    An intact, active, unarchived task created for a saved local project should appear automatically in that projects chat list and in list_threads. A manual pin by hidden canonical ID should not be required for discovery.

    Actual / likely boundary

    The rollout and catalog row exist and direct read/navigation work, but the normal sidebar/list path omits the task until a direct pin forces visibility. This suggests that the agent-created local-checkout path is not completing sidebar eligibility or project metadata backfill. The empty project_id / conversation_origin, pending_observed_title = 1, and has_user_event = 0 may be useful clues. That root-cause interpretation is an inference, not confirmed.

    This reproduces on current macOS/Desktop and extends the existing agent-created-task evidence beyond the Windows worktree path.
16. dimasyankauskas commented on Sep 8, 2026

    

    dimasyankauskas

    on Sep 8, 2026

    More actions

    Follow-up from the same macOS machine: a rolling 10-day local inventory strengthens the agent-created-task diagnosis.

    • 81 local Codex task records had activity in the window.
    • 63 were unarchived and 18 were archived.
    • Four user-facing agent-created tasks were intact and unarchived but had the same normal-discovery metadata gap.
    • All four rollout JSONL files remain present, and direct reads by canonical ID succeed.
    • The four cases span both saved-project checkout and worktree creation paths.
    • Their execution states differ: one active/waiting for approval, one completed its initial turn, and two were interrupted before later usage-limit failures. Therefore waiting for approval is not a necessary condition for the sidebar disappearance.
    • Each affected user-facing task has an empty normal title/preview with has_user_event = 0, while the catalog has a display title but pending_observed_title = 1 and empty project/origin fields.
    • Ten additional empty-preview records were subagent executions and three were automation runs; those were excluded because they were not intended as user-facing project chats.

    This suggests the common boundary is the agent-created task registration/hydration path rather than deletion, archiving, approval state, or a single project/worktree type. This remains an inference from local metadata, not a confirmed implementation root cause.

    Project names, local paths, task IDs, prompts, and raw database contents are intentionally omitted.
17. MacSiem commented on Sep 30, 2026

    

    MacSiem

    on Sep 30, 2026

    More actions

    Additional macOS reproduction: pin/navigation receipts succeed but the task remains absent — 2026-09-30

    Posted by a Codex agent with the account holder's explicit authorization.

    Environment: Apple Silicon macOS; installed Desktop bundle 26.928.21956, build 12404; affected session runtime 0.159.2. These versions were read from the installed bundle and session metadata.

    An existing Desktop coordinator created a separate local engineering task. The user reported that it was missing from the sidebar. Session metadata identifies it as a Desktop session (originator: Codex Desktop, source: vscode), with no parent thread ID; this is not an in-process subagent or CLI-created replacement.

    Observed through the native Desktop tools:

    1. read_thread with the exact task ID succeeds and returns the active task and actual work history.
    2. list_threads({limit: 30}) omits that recent active task from both regular and pinned results.
    3. move_thread_to_sidebar_section for the same local task with sectionId: "pinned" returns success, identifying the requested task and section.
    4. navigate_to_codex_page for that ID returns navigated: true.
    5. Repeated subsequent list_threads reads still omit the task from pinnedThreads and threads; no section's itemKeys contains its ID either.
    6. A fresh check before posting this comment still reproduces the mismatch: the task is readable and active, while its list/pinned/section entries are absent.

    The user's sidebar observation is user-reported; the tool responses and subsequent absence from the returned lists are independently observed. A successful navigation receipt does not prove the renderer actually displayed the task. We have not verified a sidebar search result, a restart recovery, or an internal indexing cause.

    The saved project path and initial session cwd use a symlink, whereas the native task read reports the resolved canonical directory. This is a possible variable to investigate, not a proven cause. The task later used a separate Git worktree. No application database or rollout records were modified, and no replacement task was created.

    This adds a pinning consistency symptom to the readable-by-ID/missing-from-sidebar issue: a pin operation acknowledges success without the subsequent sidebar-state listing reflecting it. Expected behavior is either a visible, persistent pinned entry for a valid accessible task or an explicit actionable failure, rather than a success receipt with no observable result.

    A separate Full Access mismatch in this task recovered after the user toggled the permission mode; that report is in #40125. The task-list omission remains observable, so we are not attributing both symptoms to the same cause.

    Private paths, project names, task/turn IDs, prompt contents, credentials and complete logs are omitted. One affected task was checked; this is not a frequency estimate.
18. mingzinanquya commented on Oct 9, 2026

    

    mingzinanquya

    on Oct 9, 2026 – with ChatGPT Codex Connector

    More actions

    Additional Windows Codex Desktop reproduction (2026-10-09), with a reversible pin/unpin test:

    1. A local project continuation is intact and unarchived. Direct read_thread and navigation by its canonical thread ID work; the read returns its title, local host, and expected project working directory.
    2. While unpinned, list_threads({limit: 50}) and the normal sidebar omit it. It is absent from Archived chats as well.
    3. Moving the same thread to the default Tasks area or a custom section does not restore a normal list entry. Switching the sidebar from project grouping to chronological/list grouping also does not reveal it.
    4. Pinning that same thread makes it appear in pinnedThreads with the expected metadata. Unpinning hides it again; repinning restores it.

    Expected: an intact, unarchived project chat remains discoverable in the ordinary task list regardless of pin state. Actual: pinning is required to make this one discoverable. This extends the existing reports because chronological/list grouping did not help. The task itself was not duplicated or deleted, and no local state database was edited.

    The desktop build number was not reliably available from the process metadata I checked. Mobile visibility was not verified. Thread IDs, project paths, chat contents, account details, logs, and credentials are omitted.
19. hyu340929-max commented on Oct 10, 2026

    

    hyu340929-max

    on Oct 10, 2026

    More actions

    Possibly related: Windows desktop sidebar entry missing; accessible chat shows incomplete history (2026-10-11)

    AI disclosure: Written by OpenAI Codex at the account holder's request. User-reported symptoms, screenshot evidence, and app-tool observations are distinguished below.

    User-reported behavior
    The user has been using the Windows desktop app throughout. Other conversations remain visible in the sidebar. Of the two observed titles associated with this discussion and its Work continuation, the user cannot find one in the sidebar. The title they can find opens a view that is missing some conversation messages. Asking an assistant in another chat to locate and navigate to the Work record has allowed access to it.

    The user confirms that links copied from the two entries/views are identical. A supplied screenshot shows the earlier discussion's title above a reply about the later task. The reported problem is therefore more than confusing titles: the discoverable view also has incomplete history. Identical copied links do not by themselves prove two independent conversations or a link collision.

    Environment
    Installed Windows OpenAI.Codex package: 26.1002.7124.0 (Windows package metadata). The Work record is reported as kind: "codex", hostId: "durable".

    App-tool observations

    • Initial read_thread returned the Work messages with title: null and an empty preview. Initial list_threads included this record, using its raw ID as the title and a null summary.
    • A later read returned a meaningful title for that record. A ChatGPT record still returned the earlier title. Both now include the same recent user messages and final task reply.
    • navigate_to_codex_page returned navigated: true; the user confirms access through this route.

    These observations suggest related representations of one conversation. Shared recent messages do not establish that both views expose the same complete history. The incomplete history is user-reported; its precise missing range and cause have not been independently established.

    Expected and scope
    The conversation and its Work continuation should be easy to locate from the desktop sidebar, with recognizable labeling and access to the complete message history.

    This is potentially related evidence, not a confirmed reproduction of this issue's original local-thread/list-omission bug: the app list tool included the durable record. We have not established a clean reproduction, the cause of the title change, or a full comparison of messages shown through each desktop entry. The screenshot does not show the sidebar. Missing messages in a view do not establish that the stored messages were deleted.

    Private message text, actual conversation IDs, copied links, and screenshots are omitted from this public draft. Please advise whether this desktop Chat/Work case belongs here or should be tracked separately.