Codex Desktop hides active project chat history while local threads remain on disk

I’m seeing what may be a related issue in Codex Desktop 26.519.81530 / bundle 3178 with codex-cli 0.133.0 on macOS.

In my case, the local data does not appear to be gone: state_5.sqlite still contains the missing project threads, and the rollout JSONL files are still present. For one affected project, I can find 6 threads locally. When querying thread/list with that project cwd, those threads are returned, but the Desktop sidebar shows "no chats" when expanding the project.

One possible explanation is that the sidebar/project chat list may be relying on the globally loaded recent thread page. In my local check, the default recent list only returned the first 50 recent threads, and this project had threads older than that page. So the project still appears in the sidebar, but its chats may not be fetched when the project is expanded.

This might be worth checking as a project-specific fetch or pagination issue rather than actual data loss. A per-project thread/list fetch on expand, or some kind of “all local chats / search history” recovery view, would probably help make these threads discoverable again.

The chat history in remote projects also has this problem. Status: Open. #25092

Additional data point from the same macOS Desktop failure mode.

Today a specific project (/Users/anguskennedy/dev/TimeTracker) shows only the current chat in the left sidebar, but the local state still contains the historical project chats.

Local evidence:

• Codex Desktop app bundle was updated/replaced on 2026-05-28 11:05 local time.
• Current Desktop version: 26.519.81530, bundle version 3178.
• Logs show client_name="Codex Desktop" client_version="26.519.81530" on May 28 and May 29.
• ~/.codex/state_5.sqlite contains 80 active, unarchived threads for cwd = '/Users/anguskennedy/dev/TimeTracker'.
• For that project, thread_source breakdown is 12 user, 15 subagent, 53 null/legacy.
• Recent visible/expected user threads include:
• 019e5058-5775-7cb3-a865-cc89df1154bd updated 2026-05-29 11:58:07
• 019e4fdc-2e9a-7880-8168-0442bf5c757e updated 2026-05-22 15:30:17
• 019e4fc6-3cd0-7ae3-b1a1-ddde3952b691 updated 2026-05-22 13:23:45
• .codex-global-state.json currently has 79 thread-workspace-root-hints entries pointing to /Users/anguskennedy/dev/TimeTracker.
• There are no thread-project-assignments and no projectless-thread-ids affecting those TimeTracker IDs.
• active-workspace-roots, electron-saved-workspace-roots, and project-order all include /Users/anguskennedy/dev/TimeTracker.
• Despite that, the Desktop sidebar still does not show the historical TimeTracker chats.

Global recency ranking may be relevant. Among unarchived source='vscode' threads, the TimeTracker user threads are ranked globally as:

rank 1   current TimeTracker chat
rank 2   another TimeTracker chat
rank 4   TimeTracker chat from 2026-05-29 11:58
rank 74  TimeTracker chat from 2026-05-22 15:30
rank 75  TimeTracker chat from 2026-05-22 13:23
rank 103+ older TimeTracker chats

So this still looks consistent with the sidebar only hydrating/rendering a global recent conversation slice, then grouping from that in-memory subset, instead of fetching all active local project threads or fetching per project on expand.

Important correction from local testing: adding/restoring thread-workspace-root-hints alone is not sufficient to restore sidebar visibility. The persisted DB rows and workspace hints can both be present while the sidebar remains incomplete.

I also reproduced the issue. GPT 5.5 says:

We patched the Desktop renderer bundle, not the SQLite data. The actual code change was in the packed app archive: /Applications/Codex.app/Contents/Resources/app.asar. Inside it, the relevant generated JS file was: webview/assets/app-server-manager-signals-DkRDRgNB.js. We changed the initial sidebar refresh from loading only the recent global slice: let t=await this.listRecentThreads({limit:50*this.recentConversationPageCount,cursor:null}); to loading all unarchived threads through the app’s existing pagination helper: let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};. Deployment detail: direct writes into the installed app bundle were blocked by macOS with EPERM, so the final installed patch was done by moving the original app aside and copying in the already-tested patched app bundle. Then I ran: codesign --force --deep --sign - /Applications/Codex.app, codesign --verify --deep --strict /Applications/Codex.app. The app is now ad-hoc signed, and future official updates may overwrite the patch.

The above change brought back chats from more than 4 weeks ago in the Sidebar, which loaded normally.

I am seeing a related Windows Codex Desktop failure mode on May 29, 2026.

In addition to important chats disappearing from the visible UI, the active thread can report that it "can't be loaded" while the thread is visibly loaded and usable in front of the user.

Sanitized local evidence:

• Platform: Windows Codex Desktop.
• Bundled codex.exe --version results:
• default bin: codex-cli 0.130.0-alpha.5
• newer hashed bin: codex-cli 0.133.0
• codex doctor could not run from a non-interactive shell: stdin is not a terminal.
• The current visible active thread exists in session_index.jsonl, but its indexed updated_at appears stale relative to active use.
• Local state/log files keep updating while the session index lags:
• global state and SQLite state/log files updated around 13:31 local time;
• session_index.jsonl was last modified around 13:26 local time;
• the active thread's updated_at in the session index was much older than the active use window.
• Repeated chat-visibility recovery backup directories are being created, suggesting the app or local repair task is already detecting visibility/index instability.

Impact:

This is a continuity/data-access issue, not just a cosmetic sidebar issue. The user can lose practical access to important project command/history chats, and now the app can also show a load failure for content that is visibly loaded.

Request:

Please investigate Codex Desktop thread/session reconciliation on Windows:

1. Active visible thread state should not disagree with load/error state.
2. Session index/global state/SQLite state should reconcile promptly during active use.
3. Sidebar/search/history should provide a first-class recovery path for local threads that exist on disk.
4. The app should surface a diagnostic bundle or safe "repair index" action instead of leaving users with apparent data loss.

@evadne Thanks for sharing this. I tried the same general workaround on macOS by patching a copy of the Desktop app bundle so that the initial sidebar refresh loads all unarchived local threads instead of only the recent global slice. That restored the previously hidden chats for an affected local project on my machine.

I did not need to modify state_5.sqlite, session_index.jsonl, or rollout files. The threads were already present and readable locally; they just were not discoverable in the Desktop sidebar. This seems to further support the theory that the problem is in sidebar hydration/pagination rather than local data loss.

I also reproduced the issue. GPT 5.5 says: > We patched the Desktop renderer bundle, not the SQLite data. The actual code change was in the packed app archive: /Applications/Codex.app/Contents/Resources/app.asar. > Inside it, the relevant generated JS file was: webview/assets/app-server-manager-signals-DkRDRgNB.js. > We changed the initial sidebar refresh from loading only the recent global slice: let t=await this.listRecentThreads({limit:50*this.recentConversationPageCount,cursor:null}); to loading all unarchived threads through the app’s existing pagination helper: let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};. > Deployment detail: direct writes into the installed app bundle were blocked by macOS with EPERM, so the final installed patch was done by moving the original app aside and copying in the already-tested patched app bundle. > Then I ran: codesign --force --deep --sign - /Applications/Codex.app, codesign --verify --deep --strict /Applications/Codex.app. The app is now ad-hoc signed, and future official updates may overwrite the patch. The above change brought back chats from more than 4 weeks ago in the Sidebar, which loaded normally.

Same issue here on Windows Codex Desktop after the latest update.

The missing chats are not deleted or archived. I can see them from mobile on the same account, but Codex Desktop shows “No chats” for affected projects. Local session files also still exist under .codex/sessions.

So this looks like a Desktop-specific local listing/index/cache or project-to-thread mapping regression, not data loss.

Adding another workaround option that does not modify SQLite/session data and also does not patch app.asar directly.

I tested this class of workaround on macOS before an official app update overwrote the local patch. The diagnosis matches what others have reported here: the thread rows and rollout JSONL files are still present, but the Desktop renderer appears to build the sidebar/search universe from a limited initial thread/list result.

Workaround: app-server stdio shim

Instead of modifying the renderer bundle, wrap the bundled codex app-server entry point with a small stdio JSON-RPC proxy:

1. Move the original launcher aside, e.g. Contents/Resources/codex -> Contents/Resources/codex-real.
2. Replace Contents/Resources/codex with a shell wrapper that only intercepts app-server launches.
3. The wrapper runs a Node proxy for codex app-server; all traffic is passed through except selected thread/list requests.
4. When the Desktop asks for the initial global recent slice, e.g. thread/list({ limit: 50, cursor: null, cwd: null, archived: false }), the proxy expands the result before returning it to the renderer.
5. Re-sign the app bundle ad-hoc with codesign --force --deep --sign - /Applications/Codex.app.

The version I tested expanded the result by reading saved workspace roots from .codex-global-state.json, then issuing per-workspace thread/list({ cwd, limit: N, archived: false }) calls to the real app-server and merging/de-duplicating by thread id. This restored missing project chats without touching state_5.sqlite, session_index.jsonl, or rollout files.

Pseudo-shape:

if (message.method === "thread/list" &&
    message.params?.cursor == null &&
    message.params?.cwd == null &&
    message.params?.archived !== true &&
    message.params?.limit >= 50) {
  const global = await callRealAppServer("thread/list", message.params);
  const roots = loadSavedWorkspaceRoots();
  const perProject = await mapWithConcurrency(roots, 4, cwd =>
    callRealAppServer("thread/list", {
      ...message.params,
      cwd,
      cursor: null,
      limit: 20,
      archived: false,
    })
  );
  return mergeByThreadIdAndSortByUpdatedAt([global, ...perProject]);
}

Tradeoffs observed

• This is less invasive than patching generated renderer JS in app.asar, and it survives renderer hash/name changes.
• It is still a local app-bundle patch and official updates can overwrite it.
• It can increase startup/sidebar refresh CPU because it fans out multiple thread/list requests. Users with many workspace roots should keep the per-project limit and concurrency conservative.
• It only makes Desktop search as complete as the expanded result set returned to the renderer. If the renderer search only searches loaded threads, a per-project limit can still miss older threads.

Safer variant

Given the app.asar workaround above changes the renderer from listRecentThreads to listAllThreads, an app-server shim can probably implement the same idea more cleanly by using the existing thread/list pagination:

const all = [];
let cursor = null;
do {
  const page = await callRealAppServer("thread/list", {
    ...message.params,
    cwd: null,
    archived: false,
    limit: 200,
    cursor,
  });
  all.push(...page.result.data);
  cursor = page.result.nextCursor;
} while (cursor && all.length < MAX_THREADS);

return { data: dedupeAndSort(all), nextCursor: null };

For a few hundred local threads this should require only a handful of app-server calls, which may be cheaper and more predictable than workspaceCount * perWorkspaceLimit fanout. It would still need guardrails: max thread count, timeout, timing logs, and a fallback to the original response on error.

This is not an official fix, but it is another confirmation that the data is normally still local and readable; the failure is in what the Desktop renderer initially loads and therefore what its sidebar/search can discover.

.

Adding one more data point with a narrower suspected trigger.

I am seeing the same Codex Desktop sidebar/search history issue on macOS: project chats disappear from the sidebar/search, but the threads are not actually lost and remain readable by thread id through the app thread API.

In my case, the pattern seems tied to long first messages:

1. Start a new project chat.
2. Put a very long prompt in the first user message.
3. Codex appears to convert/store that first message as a .txt attachment.
4. Later, the chat may disappear from the project sidebar/search.
5. Direct thread-id lookup still works, and pinning the thread manually can partially recover visibility.

I recovered several affected project threads this way and had to maintain a manual recovery index of thread ids. The most suspicious current case is a thread whose first message was long enough to trigger the .txt conversion path.

Expected behavior: attachment-backed first user messages should still create normal searchable/sidebar-visible thread index records. A long first message should not make the chat effectively disappear from project history.

This may be a more specific variant of the same sidebar/history discovery bug described here.

I'm seeing this issue on Version 26.527.31326 (3390). I can only see a max of 10 threads per project.

Adding a Windows counterpart to the macOS app.asar workaround discussed above.

I tested this on Windows Codex Desktop AppX OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0 with codex-cli 0.136.0-alpha.2.

Result: patching a copied app, not the installed WindowsApps package, restored the hidden project chats. No SQLite/session/rollout files had to be edited.

The same renderer replacement worked:

// original
let t=await this.listRecentThreads({limit:50*this.recentConversationPageCount,cursor:null});

// copied-app workaround replacement; trailing spaces preserve byte length
let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null};  

Windows-specific safety notes:

• Do not patch C:\Program Files\WindowsApps\OpenAI.Codex_* in place.
• Copy the package app directory to a user-writable location.
• Patch only the copied app\resources\app.asar and update the ASAR entry integrity hash.
• Launch the copied Codex.exe with a separate Electron profile and, if using the real history, CODEX_HOME=%USERPROFILE%\.codex.
• Do not run official Codex and the copied patched app at the same time against the same live CODEX_HOME.

Detailed Windows notes are here: https://github.com/openai/codex/issues/25500#issuecomment-4596553952

This still points to the same root cause: the project sidebar/search universe appears to be built from a limited global recent window. The real product fix should be project-scoped thread/list({ cwd, cursor, limit, archived: false }) on project expand, or otherwise correct pagination before project grouping.

My local instance is currently working again, so I am not asking for recovery help. I am adding redacted diagnostics because this previously reproduced on my machine and seems relevant to the broader sidebar/project discovery bug.
I am seeing a closely related case on macOS where local thread/session data remains intact, but Codex Desktop sidebar/project history discovery can show "No chats" or hide valid project conversations.

I posted fuller redacted diagnostics on #21119 because my local data also shows many oversized thread titles:

• SQLite integrity_check: ok
• total local threads: 224
• active/unarchived threads: 67
• rollout JSONL files: 224
• threads with title length > 1000: 155
• Codex Desktop: 26.601.21317, build 3511
• macOS: 26.3.1

One extra angle from my case: recurring/heartbeat automation threads likely amplified the issue by increasing thread volume and sidebar/index pressure. Pausing the standalone recurring automation and moving the workflow to a single persistent runner thread reduced the risk.

This looks like the same broader sidebar/project discovery bug rather than local data loss.

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.

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.

Confirming the same failure mode on a current macOS build.

Environment

• Codex Desktop: 26.715.52143 (bundle build 5591)
• macOS 26.5.2, Apple Silicon / arm64

Observed

• The left sidebar is visible, but Recent shows no tasks at all.
• Existing tasks still open directly and continue normally.
• Local state currently contains 58 active, unarchived threads.
• PRAGMA integrity_check for state_5.sqlite returns ok.
• A direct app-server thread/list request returns the existing threads.
• Desktop logs repeatedly show successful thread/list responses with errorCode=null, while the renderer still displays an empty list.
• The renderer also repeatedly logs: ResizeObserver loop completed with undelivered notifications.

Recovery attempts

• Reinstalled the app twice.
• Fully quit/restarted multiple times.
• Reset the Electron renderer profile and regenerable caches.
• Switched the persisted sidebar preference from project mode to list mode.
• Verified the clean profile and list-mode setting were active after restart.

The issue persists, so this does not appear to be database corruption or missing task data. It looks like a Desktop frontend history discovery/rendering failure after thread/list succeeds.

The in-app Send Feedback flow also fails to start a submission; no feedback upload event appears in the desktop logs. I can provide targeted sanitized log excerpts if needed.