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

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

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

   

   github-actionsbot

   on Jun 5, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop project threads disappear from project views/search while session JSONL remains readable #25463
   • Codex macOS app project sidebar can hide existing local project chats after restart/cache drift while SQLite thread records remain intact #25574
   • Codex Desktop update lost project/sidebar conversation history mapping although local sessions still exist #26157
   • Codex Desktop left sidebar only shows ~50 conversations, making older project chats disappear #25761
   • Codex app project chat history disappears after reopening app #26031

   Powered by Codex Action
3. wangyaok1 commented on Jun 7, 2026

   

   wangyaok1

   on Jun 7, 2026 – with ChatGPT Codex Connector

   More actions

   Hi everyone, I'm tracking the same Codex Desktop missing-thread/sidebar-history issue on macOS.

   For those affected here: did you eventually get all hidden project threads back in Desktop? If yes, what exact method worked durably for you?

   Examples I'm trying to distinguish:

   • official update fixed it
   • restart/reindex fixed it
   • codex resume --all <thread-id> rehydrated it
   • repairing session_index.jsonl / state_5.sqlite / .codex-global-state.json fixed it
   • Codex Wake or another local recovery helper fixed it
   • app bundle / listAllThreads patch fixed it
   • nothing worked yet

   In my case, the missing project threads still exist in ~/.codex/sessions and state_5.sqlite, but Desktop does not hydrate them back into the project sidebar after restart. Any confirmed durable fix would help. Please do not share private session contents; sanitized method/results are enough.
4. zhyuzhyu commented on Jun 8, 2026

   

   zhyuzhyu

   on Jun 8, 2026

   More actions

   Adding another macOS data point that looks like the same underlying Desktop sidebar/search history issue, with one narrower detail: affected older source='cli' threads are readable by thread ID but are omitted from Desktop search/listing.

   Environment:

   • Codex Desktop: 26.602.30954 (CFBundleVersion 3575)
   • Codex CLI: codex-cli 0.135.0
   • Platform: macOS 26.5.1 (25F80)
   • Local storage involved: ~/.codex/state_5.sqlite, ~/.codex/sessions

   Observed behavior:

   • A historical thread is not visible under the ~/ project group in the Desktop sidebar.
   • Searching Desktop/App thread search for text from that thread can surface a stale-looking result, but opening it fails or does not hydrate the thread.
   • The thread is also omitted from list_threads(query=...) for exact title/content keywords.
   • read_thread(threadId=...) succeeds and returns the full thread content.
   • Other older source='cli' threads under the same cwd show the same search omission pattern.

   Concrete local evidence:

   thread_id: 019e681e-0d44-7580-ad01-df59616096b6
   title: codex如何开启fast模式？
   source: cli
   thread_source: user
   cwd: /Users/<user>
   archived: 0
   created_at local: 2026-05-27 14:27:40
   updated_at local: 2026-05-27 14:50:02
   

   The local SQLite row exists and is active:

   SELECT id, title, source, thread_source, cwd, archived
   FROM threads
   WHERE id = '019e681e-0d44-7580-ad01-df59616096b6';

   returns:

   019e681e-0d44-7580-ad01-df59616096b6 | codex如何开启fast模式？ | cli | user | /Users/<user> | 0
   

   For the same cwd, local state contains active threads from multiple sources:

   active threads for cwd=/Users/<user>: 74
   source breakdown:
   cli: 26
   vscode: 17
   exec: 11
   subagent/guardian: 20
   

   The rollout JSONL is still present and readable. In this profile, ~/.codex/sessions was moved to ~/personal/sessions with a symlink left at the original path:

   ~/.codex/sessions -> ~/personal/sessions
   

   The old rollout_path still works through the symlink, and the file exists:

   ~/.codex/sessions/2026/05/27/rollout-2026-05-27T14-27-40-019e681e-0d44-7580-ad01-df59616096b6.jsonl
   

   So this does not appear to be simple file loss or a broken rollout path. The data is still present in SQLite and on disk, and direct thread-id reading works. The failure appears to be in Desktop/sidebar/search hydration or indexing for older local CLI-originated threads.

   Expected behavior:

   • Desktop sidebar/search should be able to discover active local source='cli' threads when they exist in state_5.sqlite and the referenced rollout JSONL file is readable.
   • If ~/.codex/sessions is a valid symlink, Desktop should either follow it or show a diagnostic if symlinked session storage is unsupported.
   • Search results should not point to a thread that cannot be opened/hydrated.

   This may be the same broad project/sidebar recent-window issue described here, but the source='cli' + symlinked ~/.codex/sessions detail may help narrow the Desktop index/hydration path.
5. wangyaok1 commented on Jun 10, 2026

   

   wangyaok1

   on Jun 10, 2026 – with ChatGPT Codex Connector

   More actions

   Adding a macOS datapoint after updating to the latest Desktop build.

   Environment:

   • macOS 15.5 (24F74)
   • Apple Silicon / arm64
   • Codex Desktop: 26.608.12217
   • CFBundleVersion: 3722
   • Local storage: default ~/.codex

   Recovery status on my affected project:

   • The update appears to have restored some previously missing threads.
   • It did not restore everything.
   • Older project threads are still missing from the Desktop sidebar/project history.
   • The local data still appears to exist. For the affected project, state_5.sqlite still has 251 active/non-archived rows with the expected project cwd.
   • Earlier checks also confirmed matching rollout JSONL/session files under ~/.codex/sessions.

   So my current result is: 26.608.12217 looks like a partial recovery, not a full recovery. It would still be very helpful to have an official full local reindex/recovery command that rebuilds sidebar/project history from durable local state.
6. fabianbaier commented on Jun 11, 2026

   

   fabianbaier

   on Jun 11, 2026

   More actions

   I’m seeing a related issue on Codex Desktop for macOS.

   Environment:

   • Codex Desktop / bundled CLI: 0.138.0-alpha.7
   • macOS: 26.3.1
   • Project: private local repo, name/path redacted

   Observed:

   • Project sidebar shows only 3 conversations for one private project.
   • Global Search can still find additional conversations from the same project.
   • Local state does not look corrupted:
     • codex doctor --summary reports thread inventory OK.
     • rollout files and state DB thread inventory agree.
     • no missing/stale rows reported.
   • Local DB has hundreds of active, non-archived thread rows for the redacted project cwd.
   • This is not simply “latest N”, because the sidebar includes an older thread while newer active project threads are omitted.

   Expected:
   The project sidebar should either show active project conversations consistently, or clearly expose the filter/pagination/“show full history” behavior that explains why Search and sidebar differ.

   Privacy note:
   Project name, path, thread titles, and screenshots are redacted because this is a private repository.
7. alibrohde commented on Jun 17, 2026

   

   alibrohde

   on Jun 17, 2026

   More actions

   Adding a current-build macOS datapoint that matches this issue.

   Environment:

   • Codex Desktop: 26.611.62324
   • CFBundleVersion: 4028
   • macOS, local storage under ~/.codex

   Observed:

   • A known local thread is not discoverable through Codex Desktop/thread search/listing, while terminal/raw JSONL access works.
   • codex_app.read_thread(threadId="019ed1c0-ca44-7472-b527-8e271f0e6f4e") succeeds and returns the thread.
   • codex_app.list_threads(query="019ed1c0-ca44-7472-b527-8e271f0e6f4e") returns [].
   • codex_app.list_threads(query="<unique title/content terms>") also returns [].
   • The row exists in ~/.codex/state_5.sqlite with archived=0, source="vscode", thread_source="user", and cwd=/Users/<user>.
   • The backing rollout JSONL exists under ~/.codex/sessions/2026/06/16/...019ed1c0...jsonl.

   I also tried opening codex://threads/019ed1c0-ca44-7472-b527-8e271f0e6f4e; macOS accepted the deeplink, but the reliable evidence here is the search/list mismatch above.

   Expected: direct app search/list should surface a known active local thread by exact thread id and/or content/title terms when read_thread can hydrate it.
8. Yevanchen commented on Jul 11, 2026

   

   Yevanchen

   on Jul 11, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced again on the unified ChatGPT/Codex macOS app.

   Environment

   • App: ChatGPT/Codex 26.707.41301 (build 5103)
   • macOS 26.4.1 (build 25E253)
   • Apple Silicon (arm64)
   • Reproduced: 2026-07-12

   Reproduction

   1. Locate an older local thread:
      • thread id: 019ec03b-3dd2-7210-9734-8ccb13636136
      • title: 筛选高星 SaaS 模板
      • status: notLoaded
      • non-archived
      • older than the global recent-50 window
   2. Call:

      {"threadId":"019ec03b-3dd2-7210-9734-8ccb13636136","pinned":true}

   3. codex_app.set_thread_pinned returns:

      {"threadId":"019ec03b-3dd2-7210-9734-8ccb13636136","pinned":true}

   4. The sidebar's Pinned section still renders only the previously pinned thread; the target thread is absent.
   5. Navigating directly to the target thread, then toggling pinned: false and pinned: true, also returns success.

   Persistence evidence

   The action is persisted successfully. ~/.codex/.codex-global-state.json contains two pinned thread IDs, including the missing target:

   {
     "pin_count": 2,
     "target_present": true,
     "pinned_ids": [
       "019f51c0-624e-7412-becb-608193d96e63",
       "019ec03b-3dd2-7210-9734-8ccb13636136"
     ]
   }

   However, the UI shows only the first pinned item.

   This narrows the failure to sidebar hydration/rendering for older notLoaded threads rather than the pin mutation or persistence layer. A pinned thread should be loaded and rendered even when it is outside the recent-50 window.
9. botx2754-eng commented on Jul 16, 2026

   

   botx2754-eng

   on Jul 16, 2026 – with ChatGPT Codex Connector

   More actions

   Adding a Windows datapoint that also reproduces for a projectless local thread, so this is not limited to project/cwd grouping.

   Environment

   • Codex Desktop: 26.707.72221
   • Bundled CLI recorded by the thread: 0.144.2
   • Windows: 10.0.26200.0
   • Reproduced: 2026-07-16
   • Default local storage under %USERPROFILE%\.codex

   Projectless reproduction

   The affected thread was created as a projectless Desktop task and is explicitly present in the persisted projectless-thread-ids state. Its output directory is under the normal Documents\Codex\<date>\... location.

   Local evidence:

   • backing rollout JSONL exists and is readable;
   • session_index.jsonl contains the thread;
   • state_5.sqlite contains the thread with:
     • archived = 0
     • source = "vscode"
     • thread_source = "user"
     • cli_version = "0.144.2"
   • read_thread(threadId=...) succeeds, returns the title/turns, and reports status.type = "notLoaded";
   • list_threads() omits it;
   • list_threads(query="<exact thread id>") returns [];
   • list_threads(query="<exact title terms>") returns [];
   • set_thread_pinned(true) returns success;
   • direct navigate_to_codex_page(threadId=...) succeeds;
   • the normal list/search path still does not enumerate the thread.

   The same restart also hid a project-associated local thread, but the projectless case is the useful discriminator: the failure persists without any saved-project root matching or Unicode project-path dependency.

   This narrows the likely fault to Desktop/app-server history enumeration or hydration for local notLoaded threads (and possibly pinned rendering), rather than missing rollout data or project sidebar grouping alone. There were only a few local user threads in this new installation, so this case is also unlikely to be explained by an older-than-recent-50 cutoff.

   Privacy note: no raw conversations, full local paths, logs, or secrets are attached.
10. jc21539 commented on Jul 28, 2026

    

    jc21539

    on Jul 28, 2026 – with ChatGPT Codex Connector

    More actions

    Current Windows reproduction on the latest Store build, with a variant that may help isolate the indexing failure.

    Environment:

    • Codex Desktop package: 26.721.4979.0 (x64, Microsoft Store)
    • Windows x64 build 26200.8875
    • Local project task

    Observed on 2026-07-28:

    1. A recently created task completed multiple turns normally.
    2. The task then disappeared from the project sidebar and normal UI discovery.
    3. The live task registry still returns it with status.type = "notLoaded", its correct project/cwd metadata, and an updated timestamp.
    4. Reading the task by exact ID succeeds and returns the complete conversation.
    5. Direct navigation to that exact task ID succeeds immediately.
    6. The task ID is entirely absent from %USERPROFILE%\.codex\session_index.jsonl.

    This has happened more than once on the same machine. In a second recent occurrence, the task remained in session_index.jsonl, but that entry's updated_at lagged the live registry by roughly three days; the task was likewise missing from the sidebar while direct navigation still worked.

    Expected:

    • Every active, unarchived task returned by the live registry should remain discoverable in the project sidebar/search.
    • session_index.jsonl should be created/updated reliably when a task is created and when later turns complete.
    • Opening by direct ID should reveal/select the corresponding sidebar entry.

    Actual:

    • Registry/read/direct-navigation paths work, but sidebar/index state diverges, making completed work look deleted.

    No transcript, repository content, credentials, or raw logs are attached. I can provide redacted local state comparisons if maintainers specify the safest fields needed.
11. kurtontheway commented on Sep 5, 2026

    

    kurtontheway

    on Sep 5, 2026

    More actions

    Adding a Windows reproduction from the merged ChatGPT/Codex desktop app.

    Environment:

    • Windows
    • Local project with older sessions hidden behind the sidebar Show more control
    • Affected sessions remain available through local Codex thread APIs and are reported as notLoaded

    Reproduction:

    1. Open a project whose older sessions are collapsed under Show more.
    2. Confirm the hidden session can still be read by its thread ID.
    3. Open Ctrl+K search and query terms from that session's title/content.
    4. The hidden session does not appear.
    5. Expanding Show more or opening the project does not make the hidden session reliably searchable.

    Expected:

    • Ctrl+K search should cover all active, non-archived project sessions, including older notLoaded threads.
    • If search intentionally uses a limited sidebar/index window, the UI should expose a full-history search/load-more path.

    This appears to match the existing reports of sidebar/search omitting older notLoaded project threads rather than deleting local session data.