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

[anguskennedy]

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

Summary

Codex Desktop is hiding existing local chat history in the sidebar/project view. The chats still exist in local Codex storage, but the desktop app does not display them, even after unarchiving, pinning, timestamp bumping, workspace-root repair, and session-index repair.

This is a data-loss-class UX issue: the conversations are the development/build history for multiple software projects and need to remain discoverable.

Related reports:

• Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540: Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk
• Feature request: show local Codex CLI sessions in the desktop app #24197: Feature request: show local Codex CLI sessions in the desktop app

This report is a macOS Codex Desktop case where active project chats are present locally but not visible in the desktop sidebar.

Environment

• App: Codex Desktop
• Bundle identifier: com.openai.codex
• Codex app version: 26.519.81530
• Bundle version: 3178
• Codex CLI version: 0.133.0
• Platform: macOS arm64
• App-server daemon: not running; doctor reports ephemeral mode

Observed Behavior

• Sidebar only shows one current project group, despite many active conversations existing for other projects.
• A known existing thread from another project could be found in local storage and rendered from its rollout file, proving the history is still present on disk.
• Attempting to restore that known thread did not make it appear in the Desktop sidebar.

Expected Behavior

• Project sidebar should show active chats for all saved/active workspace roots.
• Pinned/restored active threads should appear in the sidebar.
• A global recent limit, if present, should not cause whole projects to disappear without an explicit filter or "show more" affordance.
• Search should be able to find a known local thread ID/title if it exists in local state.

Local Evidence

Local state_5.sqlite contains hundreds of active, unarchived threads across multiple project roots. Example redacted counts:

Project A: 270 active
Project B: 185 active
Project C:  75 active
Project D:  10 active
Other projects also have active threads

Manual restoration attempt for a known existing thread:

• Set archived=0
• Cleared archived_at
• Updated updated_at and updated_at_ms to current time
• Added thread ID to pinned-thread-ids
• Added a matching thread-workspace-root-hints[threadId]
• Added/restored saved and active workspace roots
• Moved the thread to the end of session_index.jsonl with current timestamp

Result: still did not appear in the Codex Desktop sidebar.

Diagnostics

codex doctor notable output:

Codex Doctor v0.133.0 · macos-aarch64
state DB: ~/.codex/state_5.sqlite · integrity ok
log DB: ~/.codex/logs_2.sqlite · integrity ok
goals DB: ~/.codex/goals_1.sqlite · integrity ok
active rollouts: 571 files · 3.17 GB
app-server: not running (ephemeral mode)

Connectivity warnings were present in the sandboxed diagnostic context, but the issue is local sidebar/history discovery. The local databases and rollout files are present and readable.

Suspected Areas

• Desktop sidebar/project grouping may be using a stale renderer/in-memory cache rather than local state_5.sqlite / .codex-global-state.json / session_index.jsonl.
• Sidebar fetch code appears to use inbox-items with limit:200; if that or a similar global cap applies to chats, it may hide whole projects.
• Project grouping may not reload saved/active workspace roots after the app rewrites active-workspace-roots.

Impact

High. Users can lose practical access to project build history even though the data remains on disk. This makes previous architecture decisions, implementation plans, debugging context, and project history hard to recover.

Request

Please investigate and fix Codex Desktop sidebar history discovery so that:

1. Existing active local threads remain visible by project.
2. Restored/pinned threads surface immediately or after app restart.
3. Sidebar search can find locally existing threads.
4. Any recent/global limit does not silently hide whole projects.
5. There is a first-class "All chats / All projects / Search history" recovery path in the app.

[hichipli]

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.

[howhere7]

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

[anguskennedy]

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.

[evadne]

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.

[braden-hamm]

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.

[hichipli]

@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.

[Stef9332]

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.

[smartLanny]

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.

[GGBondBlueWhale]

.

[CyberChun0329]

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.