Codex Desktop silently hides project conversations outside the global recent-50 window

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

• #20833
• #20419
• #20959
• #20608
• #20254

Powered by Codex Action

This is driving me mad, and it's exacerbated by the fact that the companion tasks launched by the plugin are taking up a large amount of the 50 available slots.[ Companion/review jobs should not share the user's main Codex Desktop history feed by default #282
]( https://github.com/openai/codex-plugin-cc/issues/282)

This might actually be the reason. I also did some digging before and found this and was not sure whether this is the case. Especially because the source code of the desktop app is not available, I think. But I also had this 50 sessions limit impression, and this might explain why people complain about things disappearing. So this might actually be a feature, not a bug, but I see it really as a bug, and especially if this is not documented and cannot be changed by users.

It's a feature waiting to happen... a "load more" under older projects or something along those lines would go along way.

I’m seeing what appears to be the same issue on macOS Codex Desktop 0.129.0-alpha.15.

A thread is present locally and has the expected title in ~/.codex/session_index.jsonl:

• ID: 019d7348-09ea-76e2-9768-8fd4e3222671
• Title: REDACTED
• Rollout file exists under ~/.codex/sessions/2026/04/09/...019d7348...jsonl

But searching Codex Desktop for REDACTED (exact text from title) does not return it. The search UI instead falls back to unrelated “Recent chats.” (Thread I was looking for was outside of most recent 50 - sat at around #78.)

I also checked Codex Desktop app storage under ~/Library/Application Support/Codex; the title/session ID does not appear there, which suggests Desktop search is not querying the full local session archive / session_index.jsonl, only a narrower recent/cache index.

Expected: known local sessions with matching titles should appear in Desktop search, even if they are older than the recent chat window.

Actual: matching local session exists on disk but is missing from Desktop search.

I can reproduce what looks like the same issue on macOS with the current Codex Desktop build.

Environment:

• Codex Desktop: 26.506.31421, CFBundleVersion 2620
• Codex CLI: codex-cli 0.130.0
• Platform: Darwin 25.4.0 arm64
• Sidebar settings: Show = All chats, Sort by = Updated, Organize = Recent projects

Observed behavior:
For one local project, Codex Desktop only shows a small handful of recent chats in the project sidebar, even though many more conversations still exist locally and are visible through lower-level local state / CLI resume flows.

Local evidence:

• ~/.codex/state_5.sqlite total thread rows: 1118
• Active direct local conversations, using archived = 0 and agent_role is null: 544
• Rollout JSONL files under ~/.codex/sessions: 930
• ~/.codex/session_index.jsonl: 494 lines

For the affected project cwd, redacted as /Users/<user>/code/st_unet_wrfhydro:

• Total thread rows: 573
• Unarchived rows: 406
• Unarchived direct rows: 328
• Oldest active direct conversation: 2025-09-16 09:53:18
• Newest active direct conversation: 2026-05-12 16:48:59
• Active direct conversations updated in the last 14 days: 5

This makes the UI look like it only shows conversations from roughly the last two weeks, but the local data shows that older conversations are still present.

Global recency ranking also matches this issue's suspected failure mode. Among active direct conversations, this project's first relevant rows are at approximately:

• rank 1
• rank 2
• rank 68
• rank 77
• rank 78
• rank 81
• rank 82
• rank 101

Counts by global recency window for the same project:

• Top 50: 2 project conversations
• Top 100: 7 project conversations
• Top 200: 46 project conversations
• Top 500: 290 project conversations

So this does not look like data loss and does not look like a fixed two-week cutoff. It looks like Codex Desktop is still grouping/searching only conversations that have already been loaded from a global recent window, instead of querying/paginating all conversations for the selected project cwd.

Expected behavior:
When a project is shown in the sidebar and Show = All chats is selected, expanding/searching that project should be able to discover all persisted local conversations for that project cwd, with pagination if needed. The UI should not make older valid project conversations appear to be gone just because they are outside the currently loaded global recent set.

I’m seeing this again on Codex Desktop 26.506.31421 (bundle 2620), macOS 26.5 arm64, codex-cli 0.128.0.

Concrete repro/evidence:

• A known active older thread exists locally:
• archived: 0
• source: vscode
• rollout file exists under ~/.codex/sessions/...
• ~/.codex/session_index.jsonl contains the same thread id/title
• ~/.codex/state_5.sqlite contains the thread row
• Sidebar search for the exact known title returned No matches.
• The visible sidebar only showed a small recent subset of chats.
• By creation time, there are 102 active local threads newer than the missing thread.
• The same thread is recoverable through CLI/local session id, so this is not data loss.

Expected: sidebar search should search persisted local thread storage, not only currently loaded/recent sidebar items. If a thread exists in state_5.sqlite, is unarchived, and has a valid rollout file/session index entry, exact-title search should find it.

One clarification: this is not only a search bug. The missing thread was also not visible in the normal Chats sidebar.

Search appears to fail because it only searches the loaded sidebar/recent subset. The higher-level issue is that valid unarchived local chats outside that subset are not visible or discoverable in the Desktop UI at all.

After hours of tracking down the cause for my threads disappearing I came across this bug report that most likely explains it, since I can also "recover" threads from the CLI by "touching" them. But obviously this is not a solution.
This limitation has serious implications. Probably it was introduced for a reason (performance?), but a better solution should be a priority. For a short-term fix, at least a config setting should be introduced that allows the history limit to be changed manually.

I actually spent my precious Codex quota debugging this bug. WTF

I can add a Windows Codex Desktop reproduction with a concrete local workaround that confirms this is a finite global recent-window problem, not data loss.

Environment:

• Codex Desktop: 26.519.5221.0
• Platform: Windows
• Local stores involved:
• %USERPROFILE%\.codex\state_5.sqlite
• %USERPROFILE%\.codex\.codex-global-state.json
• %USERPROFILE%\.codex\session_index.jsonl
• %USERPROFILE%\.codex\sessions\...\rollout-*.jsonl

Observed behavior:

• Multiple project groups in the Desktop sidebar showed No chats / incomplete chat lists.
• The underlying chats still existed locally.
• For the affected projects, state_5.sqlite had live, unarchived thread rows and all matching rollout JSONL files existed.
• The project disappeared only from the Desktop sidebar/project view.

Concrete project A:

• Live local project threads: 13
• Rollout files present: 13
• Before workaround, only 6/13 were inside the global rollout-file mtime top-50 window.
• Desktop sidebar showed only a subset of this project.

Workaround test:

• I changed only filesystem LastWriteTimeUtc on the 7 missing project rollout JSONL files.
• I did not edit JSONL contents.
• After reopening Codex Desktop, all 13 project chats appeared in the project sidebar.
• A post-workaround dry-run showed 13/13 project threads in the global rollout-mtime top-50 window.

Concrete project B:

• Live local project threads: 3
• Rollout files present: 3
• Global rollout-mtime ranks: 89, 90, 93
• Desktop sidebar showed No chats for that project.

Global diagnostic on the same machine:

• Live local threads: 112
• Live rollout files: 112
• Workspaces with live threads: 23
• Projects fully represented in the global top-50: 7
• Projects partially represented in the global top-50: 5
• Projects with live local threads but 0 threads in the global top-50: 11

Important secondary finding:

• Simulating promotion of project B's 3 rollout files would make those 3 project chats visible, but would displace the current rank 48-50 threads from another project.
• So local touch/mtime promotion is only a workaround that redistributes the limited 50 visible slots. It is not a real fix for local history visibility.

Expected behavior:

• When a project is expanded in the sidebar, Codex Desktop should fetch/paginate threads for that specific cwd / workspace root from durable local state.
• The project sidebar and search should not depend only on conversations already hydrated from a global recent cache.

Actual behavior:

• Valid unarchived local project chats outside the global recent window are hidden, and whole projects can show No chats even though their local threads and rollout files exist.

Suggested fix direction:

• Keep the global recent cache for the flat recent chat list if needed.
• For project groups, load by project/workspace cwd with pagination.
• For search, query durable local thread storage rather than only the currently hydrated sidebar subset.
• Avoid rendering No chats when local state contains matching live threads outside the global recent window.

I can reproduce this on macOS with Codex Desktop 26.519.41501.

The affected project has multiple existing local conversations, but the Desktop sidebar shows the project as empty.

The behavior appears tied to the hardcoded global recent-thread window:

• A global recent query with limit=50 does not include any conversations from the affected project.
• Increasing the same query to limit=100 includes the missing project conversations.
• The newest affected project conversation is just outside the first 50 global recent conversations.

This makes the project appear to have no chats even though the conversations still exist and can be recovered through lower-level local state / direct thread lookup.

The main problem is that this limit does not seem configurable. 50 may be reasonable for the initial global recent list, but it is not reasonable as the effective visibility boundary for project history.

Expected behavior:

• Opening or expanding a project should query/paginate conversations for that specific project/workspace.
• The sidebar should not show an empty project merely because its conversations are outside the first 50 global recent items.
• The recent-thread preload limit should either be configurable as a short-term mitigation, or not be used for project-history visibility at all.

Adding another macOS reproduction on a newer Codex Desktop build, with paths/project names/thread IDs redacted.

Environment:

• Codex Desktop: 26.519.41501 (CFBundleVersion 3044)
• Platform: macOS arm64
• Local stores checked: ~/.codex/state_5.sqlite, ~/.codex/session_index.jsonl, ~/.codex/sessions/.../rollout-*.jsonl

Observed behavior:

• In the left sidebar, a pinned local project shows only 5 recent chats.
• An older but still active project chat was not visible in that pinned project section, which made it look like the chat had disappeared.
• The missing chat was also hard to recognize because its stored threads.title was the full first user message, so the visible title would be a long truncated prompt rather than a short generated title.

Local evidence, redacted:

active unarchived threads for the affected project: 24
threads visibly rendered under the pinned project section: 5
rank of the known missing chat by updated_at_ms within that project: 8
archived value for the missing chat: 0
rollout JSONL file exists: yes
session_index.jsonl row exists: yes

The top of the project-local ordering looked like:

rank 1-5: rendered in the pinned project sidebar
rank 6: active project chat, not rendered in the pinned project section
rank 7: active project chat, not rendered in the pinned project section
rank 8: known missing active project chat, not rendered in the pinned project section

So this was not data loss. The local SQLite row, session index entry, and rollout file all existed. The issue was that the pinned project sidebar only exposed a small recent subset, making valid project history appear missing.

I also found a related metadata problem in the same repro:

threads.title == first_user_message for the affected chat

That meant even if the row surfaced elsewhere, the UI title could be an unhelpful/truncated first prompt rather than a recognizable short title. Manually normalizing only the local title metadata made the chat easier to identify, but it does not address the core visibility problem.

Expected behavior:

• A pinned project should not silently show only 5 chats without an affordance such as "show more" / "show all" / "showing 5 of N".
• Expanding or opening a project should query/page project-scoped threads from durable local state, not only render the subset already loaded for the global recent list.
• Search and project browsing should be able to discover active unarchived local threads outside the visible pinned-project subset.
• Long threads.title = first_user_message rows should not degrade discoverability; Desktop should derive/store a short usable title or fall back gracefully.

This reproduces the same class of bug as this issue: valid local project history exists, but Desktop UI presentation makes it appear missing.

I have a current macOS reproduction that matches this failure mode and adds a pinned-thread angle.

Environment:

• Codex Desktop: 26.519.81530 (CFBundleVersion 3178)
• macOS: 26.5 (25F71), arm64
• Host/control setup: Codex Desktop running on a Mac Mini, controlled from a MacBook Pro through the remote/control workflow

Observed:

• A project thread disappeared from both the project sidebar and pinned threads on the MacBook Pro controller.
• Looking directly on the Mac Mini host through screen sharing, the same thread was also absent from the project sidebar and pinned list.
• The local SQLite row still exists and is not archived.

Local evidence, with project path redacted:

thread_id: 019e4cd0-4b08-7520-b74e-f0d42f1fb3ba
created: 2026-05-21 16:12:59 PDT
updated: 2026-05-22 10:03:31 PDT
archived: 0
source: vscode
thread_source: user
cwd: /Users/<user>/Documents/Codex/projects/<project-name>
title_len: 1709
dynamic tools: read_thread_terminal

The important recent-window signal:

active unarchived user threads: 169
newer than affected thread: 54
affected thread global rank by updated_at: 55
rank 50 updated_at: 2026-05-22 12:12:57 PDT
rank 55 updated_at: 2026-05-22 10:03:31 PDT

So the affected thread is just outside the apparent global recent-50 window, even though it is a valid unarchived user thread whose cwd exactly matches the project.

Pinned state detail:

~/.codex/.codex-global-state.json currently contains only three pinned-thread-ids
this affected thread_id is not present there

The user remembers pinning this thread from the MacBook Pro controller, and also reports that several pinned threads may have disappeared. I cannot prove from local state whether the pin was lost, overwritten, or never persisted, but the end result is that a still-existing unarchived project thread is absent from the UI and the pinned list.

This appears to be the same sidebar/history loading problem described here, with an additional symptom that pinned state may not protect a thread from disappearing or may itself be getting lost in a remote-control setup.

I can confirm this on another Codex Desktop setup, triggered after using "Imported agent setup". In our case the failure happened in two stages, and the second stage matches this issue very closely.

Environment:

• Codex Desktop: 26.527.31326
• bundled Codex CLI: 0.130.0
• macOS
• local state still present in ~/.codex/state_5.sqlite and ~/.codex/sessions/...

Stage 1: external-agent import timestamp collapse

• Codex imported 50 Claude Code chats.
• The imported threads were written with import-time created_at / updated_at, instead of their original conversation timestamps.
• This made the imported Claude Code chats dominate the top of history, so older native Codex chats looked missing even though the local SQLite rows and rollout files were still present.
• Directly archiving/changing only SQLite rows was not durable because Codex rehydrated metadata from rollout files on restart.

Durable local workaround for stage 1:

• Quit Codex Desktop.
• Back up SQLite and rollout files.
• For each imported thread, derive original min/max timestamps from the source Claude Code JSONL.
• Rewrite the imported Codex rollout session_meta timestamp / payload timestamp to the original first-message time.
• Touch the imported rollout file mtime to the original last-message time.
• Update SQLite threads.created_at, threads.updated_at, created_at_ms, and updated_at_ms to match.
• Restart Codex Desktop.

After that, imported Claude Code chats and native Codex chats were chronologically interleaved again in Recents.

Stage 2: project sidebar still showed No chats
After fixing the import timestamps, several saved project folders still showed No chats, even though direct local inspection and thread/list by cwd returned matching native Codex threads.

Our local evidence matches this issue:

• Desktop app snapshot reported thread_count_loaded_recent=54.
• The affected projects' newest matching threads were outside the initial global Recent window:
• first matching project thread ranks included 123, 205, 211, 234, 235, and 268.
• Adding/rebuilding project mapping keys such as thread-workspace-root-hints, thread-project-assignments, sidebar-project-thread-orders, and pinned-project-ids did not restore the project groups.
• Pinning one hidden old thread also did not force hydration.
• Bumping one affected project thread's updated_at / updated_at_ms so it ranked near the top made that project group immediately show the chat.
• Bumping all affected project threads into ranks 1-40 restored the missing project groups.

That strongly supports the hypothesis here:
The Desktop sidebar has saved project roots, but fills project group threadKeys only from the currently hydrated global Recent conversation cache. If a project has no threads inside that cache, the project row still renders but appears as No chats.

Suggested fix:
When rendering or expanding a saved local project group, Desktop should lazily hydrate that project's threads with thread/list scoped by cwd / workspace root, with pagination. The UI should not infer No chats from an empty global Recent subset.

Related import-specific issue: #21376

Written by Codex

Adding another current macOS reproduction on Codex Desktop 26.527.31326 / bundle 3390 with bundled codex-cli 0.135.0-alpha.1. This one includes a local bundle workaround that confirms the issue is the renderer's finite global recent hydration window, not missing local thread data.

Environment:

• macOS arm64
• Codex Desktop: 26.527.31326 (CFBundleVersion 3390)
• Bundled CLI: codex-cli 0.135.0-alpha.1

Observed:

• A saved local project appeared in the Desktop project UI with No chats / no visible chat items.
• The project is present in .codex-global-state.json under saved/project order state and is not marked projectless.
• Local SQLite still has two unarchived source='vscode' threads for that cwd.
• Direct turn pagination still works for those thread ids; e.g. thread/turns/list returns turn data, so the chats are readable by the app-server.

Exact app-server signal:

thread/list({
  limit: 50,
  cursor: null,
  sortKey: "updated_at",
  modelProviders: null,
  archived: false,
  sourceKinds: []
})

returned no threads for the affected project. The same request with limit: 100 returned both project threads at global ranks 87 and 94.

That matches the failure mode described here: the project page/sidebar groups from the globally hydrated recent conversation subset. If a project has no conversations in that subset, the project can render as empty even though durable local state contains valid unarchived threads.

Local workaround that confirmed the cause:

• I patched the installed Desktop app bundle only for testing, changing the generated renderer field from recentConversationPageCount=1 to recentConversationPageCount=3 inside /Applications/Codex.app/Contents/Resources/app.asar.
• This makes the startup refresh request 50 * recentConversationPageCount, so it hydrates 150 recent threads instead of 50.
• After a full quit/reopen, the affected project's chats reappeared.
• No SQLite rows, rollout JSONL files, or session index entries needed to be changed.

This is not a recommended user workaround because it modifies a signed app bundle and will be overwritten by updates. It is useful as a confirmation that the data is present and the visibility bug is in Desktop hydration/project grouping.

Proposed product fix:

1. Keep the small global recent preload only for the flat Recent/All chats view.
2. When rendering or expanding a saved local project, issue a project-scoped thread/list query using that workspace root / cwd, with cursor pagination.
3. Merge project-scoped results into the existing conversation cache by thread id instead of treating the global recent cache as the whole searchable/sidebar universe.
4. Sidebar search should query durable local thread storage, or at least page beyond the already hydrated subset, rather than searching only currently loaded recent ids.
5. The UI should not show No chats until a project-scoped fetch has completed and returned no rows. Ideally show a load-more affordance or showing N of M style state.
6. Add a regression test with more than 50 global active local threads where a saved project's newest thread is outside rank 50; expanding that project should still show its threads.

Written by Codex.

I am having the same issue as others. While I understand the UI limitation of showing endless past chats, I do not understand the search only searching that limited group of chats. I have long running chats, for projects developing over time and am also experiencing them dissapearing before project completion.

I do use the archive function alot, so I do need to have more than the shown list accessable.

It seems weird to need a Codex chat to find, and reactivate past chats, although annoyingly that process prematurely is hiding a different active chat.

Could OpenAi in it own development not just ask Codex to add a "Show all" option that replaces the active chat with a list of all active chats in that project.

Eg at the end of the cuurent shown project chat list change the options to

Show More / Show All

or

Show Less / Show All

It's hardly complicated to do, but will but make the software so much more useful. It took me a while to realise my chats weren't just being lost, causing unnecassary distress which I am sure is happening to many people especially the more casual user

Retracted. I opened a separate standalone issue for this report instead: #25761

Adding one more macOS data point, mostly for the search/open path rather than data loss.

Environment:

• Codex Desktop 26.601.21317 (CFBundleVersion 3511)
• macOS
• A projectless Codex Desktop thread, later recovered and moved into a normal project cwd

What happened:

• A known older thread titled Fix Atlas PDF extension was difficult to reopen from search/history: clicking the search result did not open the thread.
• The underlying local data was intact:
• ~/.codex/state_5.sqlite had an unarchived source='vscode', thread_source='user' row for the thread.
• The rollout JSONL existed under ~/.codex/sessions/2026/05/15/....
• ~/.codex/session_index.jsonl contained the same title/thread id.
• Direct app-side read by id could load the turns.
• After a pin/title refresh and a full Codex Desktop restart, the user was able to open it. After the thread was later moved into a normal project cwd, exact-title search now returns it again.

Why I think this belongs here:

• This was not data loss; it looked like sidebar/search/open navigation had stale or incomplete knowledge of a locally readable thread.
• I cannot honestly claim a clean current recent-50 rank reproduction because the recovery steps updated the thread metadata. But the symptom matches this issue: persisted unarchived thread present locally/readable by id, while the UI search/open route initially failed.

Expected:

• Search/open should be backed by persisted thread storage or should refresh before navigation.
• Clicking a search result for an existing unarchived local thread should open it without requiring pin/title repair or app restart.

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.

I’m seeing this too on Codex Desktop macOS.

Local evidence:

• ~/.codex/state_5.sqlite has 11,621 thread rows.
• Oldest local thread row: 2026-01-06 local time.
• Latest row: 2026-06-08 local time.
• Active rows: 11,449.

But Codex Desktop / thread search did not find known older titles that exist locally. Recent threads search fine.

The failure mode is that older conversations feel deleted or inaccessible from the UI, even though the local DB still has them. I eventually found them through terminal/SQLite, but it took a lot of fighting.

Expected: sidebar/search should query the full local thread index, or at least expose archived/older results clearly.

Actual: UI appears limited to a recent loaded/indexed window.

My patch here is :

Patch /Applications/Codex.app/Contents/Resources/app.asar: replace the single byte string let t=await this.listRecentThreads({limit:50*this.recentConversationPageCount,cursor:null}); with same-length let t={data:await this.listAllThreads({modelProviders:null,archived:!1}),nextCursor:null}; , after backing up the original ASAR.`

Then fully quit and reopen Codex.

50 Convo really isn't much, Incredible how long it takes to fix this major issue.

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. This still appears consistent with an incomplete sidebar/project-history reindex rather than data loss.

Adding another macOS datapoint that matches the current behavior reported above.

Environment:

• macOS / Apple Silicon
• Codex Desktop: 26.608.12217
• CFBundleVersion: 3722
• Local storage: default ~/.codex
• Same ChatGPT account before and after subscription upgrade / re-login

Observed behavior:

• After upgrading my subscription and re-logging in with the same account, many existing project conversations disappeared from the Desktop sidebar.
• The affected project groups show no conversations or only a partial subset.
• Older project threads are still missing after fully quitting and reopening Codex Desktop.

Local evidence:

• ~/.codex/sessions still contains 415 rollout JSONL files.
• ~/.codex/archived_sessions contains 13 archived rollout JSONL files.
• ~/.codex/state_5.sqlite is readable and passes pragma integrity_check.
• The threads table still contains the expected local thread records.
• I manually backfilled missing thread_source values for source='vscode' rows to thread_source='user', then ran a WAL checkpoint and fully restarted the app.
• This restored some visibility, but not all older project conversations.

Current shape:

• Active/non-archived user threads exist beyond the recent visible range.
• For example, some affected project threads rank around 50-250 by updated_at, and older project conversations remain hidden from the sidebar even though they still exist in state_5.sqlite and the rollout files.

This looks consistent with the remaining global recent-window / incomplete project-history reindex issue rather than actual data loss. It would be helpful to have an official full local reindex/recovery command that rebuilds Desktop sidebar/project history from durable local state.

I think this may be fixed with the latest release?

@peterpeirce yes it has been fixed in the latest update.

There are still hidden threads on my end in project, dont think its fixed. Can anyone else verify?

The UI list should be backed by a project-scoped session index, not a filtered recent-global window. Store project key, git root/cwd, thread id, title, updated_at, archived/pinned state, and index status. Search should query that index directly and report skipped/corrupt rows, so old project history looks stale only when the data is actually missing.

---

_Generated with ax._

Hi @ashe0047 asked if other people were having similar issues. I certainly have had the full thread show and now can see more of my active threads, but I am still experiencing a few issues still. Threads seems to randomly disappear. I can not work out if this is due to incorrectly sorting, or some other random issue.

Threads on my desktop computer have reappeared but they don't realiably show if access via the mobile app, even new chats.

I think this all is working better but not fixed. Mobile seems worse, but I hardly use that so it's hard to be specific about what is normal vs broken

Hi @ashe0047 asked if other people were having similar issues. I certainly have had the full thread show and now can see more of my active threads, but I am still experiencing a few issues still. Threads seems to randomly disappear. I can not work out if this is due to incorrectly sorting, or some other random issue. Threads on my desktop computer have reappeared but they don't realiably show if access via the mobile app, even new chats. I think this all is working better but not fixed. Mobile seems worse, but I hardly use that so it's hard to be specific about what is normal vs broken

The conversation list in sidebar seems to have been fixed in the latest version on macos Codex app as I can see all the conversations for each of my project now but i cannot confirm for mobile Codex. The last time i checked, the conversation list in codex mobile is indeed a mess

I can reproduce this on current Codex Desktop for Windows, with an additional persistence failure after a normal Windows shutdown/restart.

Environment

• Codex Desktop package: OpenAI.Codex 26.721.11231.0
• Windows 11 Pro 25H2, x64
• OS build: 26200.8973
• Effective CODEX_HOME: %USERPROFILE%\.codex
• Microsoft Store reported no newer package version available.

User-visible sequence

1. Six local projects and their existing chats were visible after recovery.
2. I created another local project and continued working normally.
3. I shut down Windows normally and started the computer again.
4. On the next launch, projects/chats disappeared from the Codex sidebar or projects showed No chats.
5. The underlying project folders and conversation data were still present on disk.

This has happened more than once and interrupts active work because the UI looks as if project history was deleted.

Read-only diagnostic evidence

The core data was healthy:

sqlite_integrity: ok
threads_total: 67
threads_active: 67
real_threads_active: 11
service_threads_active: 56

For the restored project state:

projects: 6
thread_project_assignments: 9
sidebar_project_orders: 6
assigned_threads_in_sqlite: 9
assigned_rollout_files_present: 9
assigned_threads_missing_from_sqlite: 0

However, only 2 of the 9 real project threads were inside the global top-50 active-thread window. The other 7 were ranked:

59, 60, 61, 62, 63, 64, 67

All nine real project threads had interactive source vscode, no agent role, and an existing rollout file. The 56 internal/service/subagent threads consumed most of the recent window.

Pinning the nine real threads made them visible under a global Pinned section, but their projects still displayed No chats. After restoring the existing thread-to-project assignments, the conversations appeared under their projects again. No transcript had been deleted.

There was also a separate state-persistence symptom after restart: the desktop project registry/assignments could collapse even though state_5.sqlite, session_index.jsonl, and rollout files remained intact. An initial post-failure state inspection showed no saved/active roots and no thread hints.

Official diagnostics were additionally blocked on this installation: codex doctor --summary --ascii resolved to the packaged executable under WindowsApps and returned Access is denied, both inside and outside PowerShell.

Expected behavior

• Project chats should be loaded by project cwd with pagination, not inferred only from a global recent-50 cache.
• Internal subagent/service threads should not evict real user conversations from the project sidebar.
• Local project registrations and assignments should survive a clean Windows shutdown/restart.
• If the desktop sidebar state diverges from the healthy core database and rollout inventory, Codex should rebuild it automatically.
• The UI should not say No chats when active, non-archived threads for that project exist.
• Please provide a supported repair/reindex command that does not require editing private JSON/SQLite state.

Privacy

No raw database, session transcript, authentication file, project name/path, or rollout content is attached publicly because these can contain private work. I can provide specifically requested, redacted diagnostic fields if maintainers identify what is needed.

This Windows case independently confirms the global recent-50 failure described in this issue, and suggests it can combine with a restart-time project/sidebar state persistence problem. It also overlaps with #25500 and #26990.

I can reproduce this on the current Codex Desktop for Windows, and the current failure is not limited to old threads.

Environment

• Codex Desktop AppX: 26.727.6591.0
• Windows 11 Home Single Language, x64
• OS version/build: 10.0.22631
• Effective local storage: default %USERPROFILE%\.codex

User-visible behavior

After restarting Codex Desktop, one local project shows exactly 5 tasks in the sidebar and in the project hover card. Unlike other projects with more history, this project has no Show more control.

Project search also returns no match for the missing tasks.

Most importantly, one missing task is the second most recently updated active local task in that project (updated on 2026-08-02). This rules out the expected explanation that only old history is hidden.

Read-only local evidence

The durable data is intact:

sqlite_integrity=ok
threads_total=104
project_rows=9
project_active_non_archived=8
project_archived=1
active_rollout_files_for_project=8
all_project_thread_ids_present_in session_index.jsonl

For the affected project:

• UI/sidebar/hover card: 5 tasks
• state_5.sqlite: 8 active, non-archived user threads with the same project cwd
• rollout files: all 8 active session JSONL files exist
• session index: all project thread IDs are indexed
• hidden threads are source='vscode', thread_source='user', agent_role IS NULL, archived=0
• hidden threads can still be read directly by thread ID, so this is not transcript loss

The exact set of five project threads returned by the current recent thread catalog matches the five shown in the sidebar. The three other valid active threads are absent from that catalog. The catalog API also enforces limit <= 50.

The current Desktop bundle still renders project thread lists with maxItems=5. For this affected project, the project-scoped catalog incorrectly reports no more data, so the UI does not render Show more even though three additional active matching rows exist.

Pinning the hidden thread IDs is a partial workaround: it can expose them in the global Pinned section, but it does not correct the project count/history.

Expected behavior

• Expanding a project must query the full project-scoped local index by canonical cwd, with pagination.
• A project with 8 active threads must not report 5 as its total or suppress Show more.
• Search must query persisted local thread metadata, not only the currently loaded global subset.
• A very recent valid local thread must not disappear after restart because unrelated global/cloud/service items consumed the loaded window.
• Desktop should rebuild/reconcile project history automatically when SQLite, session files, and the session index are healthy.

No raw database, session transcript, thread ID, private project name/path, task title, authentication data, or logs are attached publicly. I can provide specifically requested redacted fields if maintainers identify what is useful.

Adding a current macOS reproduction from Codex Desktop 26.727.51351 (build 6119) with bundled codex-cli 0.146.0-alpha.9.2. All diagnostics below were read-only, and project names, paths, titles, messages, and thread IDs are intentionally redacted.

Summary

This is still reproducible. The underlying conversation store is healthy, but Desktop exposes only a small recent projection and the newer local thread catalog is not completing its initial build. In practice, entire projects appear to have no history even though their conversations remain intact and directly readable.

Durable-store evidence

PRAGMA integrity_check returns ok for the primary state database.

state_5.sqlite:
  total thread rows:       1,898
  active rows:             1,867
  archived rows:              31

rollout JSONL files:
  active:                  1,867
  archived:                   31

The database and rollout-file counts match exactly, so this is not deletion.

Using a conservative direct-conversation filter:

archived = 0
and agent_role is null
and source in ('vscode', 'cli')
and coalesce(thread_source, '') not in ('automation', 'subagent')

there are 905 active direct conversations.

Recent-window evidence

The current Desktop task-list surface rejects a requested limit above 50 with:

limit: Too big: expected number to be <=50

A normal call returns exactly 50 rows. In the observed result, 24 of those rows came from a separate managed-agent runtime, leaving less than half of the window for ordinary project work.

Ranking the 905 direct conversations globally by updated_at gives this boundary:

rank 50: 2026-08-01 04:22 local
rank 51: 2026-08-01 03:01 local

Sanitized project impact:

Project A: 42 active direct conversations; 1 in global top 50
Project B: 38 active direct conversations; 0 in top 50; newest rank 68
Project C: 26 active direct conversations; 0 in top 50; newest rank 406
Project D: 20 active direct conversations; 0 in top 50; newest rank 540

An older Project A conversation outside the visible list remains directly readable by its known thread ID, returning notLoaded rather than missing or corrupt.

New catalog-layer evidence

The current app also maintains ~/.codex/sqlite/codex-dev.db. Its integrity check is ok, but the catalog is incomplete:

local_thread_catalog rows:                  109
distinct catalog cwd values:                 10
local_thread_catalog_sync_state:
  initial_build_complete:                     0
  watermark_updated_at:                    NULL
  last_full_reconciled_at:                 NULL
  observation_sequence:                     899

The 109 catalog rows have source update times only from June 25 through July 17, while the primary state database contains valid activity through August 3.

This suggests the current failure has two related layers:

1. The original global recent-50 projection still prevents reliable discovery of older project conversations.
2. The newer local catalog can remain indefinitely incomplete, so it does not provide a durable full-history fallback.

Expected fix behavior

A durable fix should:

1. Build project history from an authoritative, paginated snapshot of all persisted user-visible threads, not a global recent subset.
2. Mark initial_build_complete only after every page has been consumed and committed.
3. Retry or force a full reconciliation when the completion flag is false, the watermark is null, or catalog coverage is inconsistent with the primary store.
4. Keep subagent, automation, and managed-runtime threads from consuming the ordinary top-level conversation discovery window.
5. Search the persisted catalog, not only IDs already loaded into the sidebar.
6. Expose a supported “rebuild local conversation index” diagnostic action and report skipped/corrupt rows instead of showing “No chats.”

I have not patched the app bundle, changed timestamps, rewritten SQLite state, or modified sidebar metadata. The missing history is currently recoverable by direct thread ID, but there is still no reliable UI path to enumerate it.

I can still reproduce this on the current Windows Codex Desktop build, even though the newer local_thread_catalog is fully populated and healthy.

Environment

• Codex Desktop: 26.803.5235.0
• Embedded app-server runtime reported by Desktop: 0.147.0-alpha.6.5
• Platform: Windows 11 x64 (10.0.26200)
• Authentication: ChatGPT account login
• Sidebar mode: Projects

Current symptom

Several registered local projects show No chats, while their active conversations still exist and can be resumed from the CLI. This persists after fully exiting and reopening Desktop.

The affected project names, paths, thread IDs, and titles are redacted below.

Durable-state evidence

state_5.sqlite:

total thread rows: 1292
active/unarchived rows: 1234
active direct vscode/cli rows: 899

codex-dev.db:

local_thread_catalog rows: 1113
host_id=local, model_provider=openai, missing_candidate=0: 1113
local sync initial_build_complete: 1

Three projects that Desktop renders as No chats have the following valid catalog counts:

Project A: 1
Project B: 8
Project C: 3

For each sampled thread:

• the rollout JSONL exists;
• state_5.sqlite has an active, unarchived row;
• local_thread_catalog has the same thread ID, exact project cwd, host_id=local, model_provider=openai, and missing_candidate=0;
• provider metadata is aligned between config, SQLite, and readable rollout metadata.

Stronger catalog-reader evidence

I extracted the page-query logic from this installed Desktop build and reproduced its readManualPage SQL against the same codex-dev.db. Using the same project root, include/exclude sets, host ID, and manual thread order, the query correctly returns the hidden thread and its title.

Desktop nevertheless renders the project as No chats. Sysinternals Handle also confirms that the active Desktop main process has this exact database open:

%USERPROFILE%\.codex\sqlite\codex-dev.db

Changing the sidebar project sort between priority/manual and restarting did not change the result. Rebuilding large sets of thread-project-assignments also did not help and was rolled back, because it only creates misleading empty project groups.

This suggests the current failure is after durable catalog lookup: the renderer/catalog reader is not materializing valid page results into the project list, or is exhausting/caching the project scope as empty before the valid catalog page reaches it.

Reproduction

1. Accumulate enough local conversations that a project's chats are outside the globally hydrated recent set.
2. Verify that the project still has active rows in state_5.sqlite and valid rows in local_thread_catalog.
3. Fully exit and reopen Codex Desktop in Projects mode.
4. Expand the affected project.
5. Desktop displays No chats, despite the complete catalog and resumable thread IDs.

Expected behavior

Expanding a project should render/paginate every valid catalog entry matching that project scope. The UI should not display No chats when local_thread_catalog already contains matching, non-missing entries.

This appears to be the Windows/current-build continuation of the original recent-window problem: the durable per-project catalog now exists and is complete, but older project conversations are still not surfaced by the Desktop UI.

Reproduced again on 2026-08-12 after a normal, deliberate macOS restart.

Environment:

• macOS 26.6.1 (25G76)
• Codex Desktop session metadata: cli_version: 0.147.0-alpha.6.5
• Local user-owned Codex task; no host was unavailable

Observed sequence:

1. A long-running local task remained active through 11:05 IST.
2. The goal was paused, project state was verified, local services were stopped, and macOS was restarted normally.
3. After restart, the task did not appear in the project/sidebar or recent-task listing.
4. The local rollout remained intact at approximately 109 MB.
5. Reading the task directly by its opaque ID succeeded and returned the correct Codex task and latest turn with status notLoaded.
6. Navigating directly to that ID successfully reopened the task.
7. The recent listing returned exactly 50 non-pinned ChatGPT conversations, no Codex tasks, and unavailableHosts: [].

A potentially important additional clue: the affected thread reported identical creation and update timestamps:

createdAt: 1786486813  (2026-08-11 23:20 IST)
updatedAt: 1786486813  (2026-08-11 23:20 IST)
last completed turn: 1786529107 (2026-08-12 11:05 IST)

So updatedAt did not advance despite roughly 12 hours of later task activity. Combined with the global recent-50 window, that stale timestamp appears to let a genuinely recent/active task fall outside the loaded set after the app restarts and loses its already-loaded in-memory reference.

Expected:

• Completing or receiving a turn should advance the thread's sort/update timestamp.
• Project history and sidebar search should query persisted project threads, not only the global recent-50 subset.
• A locally persisted task should remain discoverable after restart without requiring its opaque ID.

This has occurred periodically, not just once. Private task IDs, paths, titles, and prompt contents are intentionally omitted.

If older project chats vanish from Desktop after a restart or about a week of inactivity, the data is usually still on disk. Desktop only loads a recent window (often 50 items) and then groups or searches that already-loaded subset.

Method:

1. Pin any thread you must keep visible.
2. From a terminal, run codex resume --all and open the missing thread by id or name. If you already have the opaque thread id, opening that id in Desktop also works (it can show as notLoaded, then the task reappears).
3. Once it is open, pin it or update it so it stays inside the recent window.
4. Before assuming anything was deleted, confirm the local store is healthy: state_5.sqlite still has the thread and PRAGMA integrity_check returns ok.

Evidence: current Windows and macOS reports (including 26.803 / 0.147.0-alpha) show intact local stores plus a 50-item recent projection. codex resume --all is the supported way to list beyond cwd and recent filtering.

Independent community workaround; not an official OpenAI fix.

@naipi11 Thank you — this workaround was very useful and worked in my case.

I verified it on Windows with Codex Desktop 26.818.5229.0 and CLI 0.148.0:

• The missing thread was still present in state_5.sqlite, and PRAGMA quick_check returned ok.
• Resuming the thread by its ID loaded the complete historical transcript successfully.
• Pinning it afterward made it visible and directly openable in Desktop again.

One detail from my test: resuming alone refreshed/opened the thread, but did not reliably restore its persistent project assignment. Pinning after resume was the important step for keeping it visible. So this is a very effective recovery workaround, although it does not appear to be a full fix for the underlying project/sidebar indexing issue.

Thanks again for documenting it.

Thanks for confirming the Windows result. The extra pinning step is useful because resume can refresh the thread without restoring its persistent project/sidebar visibility.

This should still be treated as a recovery workaround, not a fix for the underlying project/indexing issue. If the task becomes hidden again after a restart or resume, preserve the state and report the exact build rather than editing the database.

Reproduced again on macOS on 2026-08-23 with a current ChatGPT/Codex desktop build.

Environment

• ChatGPT/Codex desktop: 26.818.31338
• Bundle build: 6892
• Platform: macOS, Apple Silicon
• unavailableHosts: []

Privacy-minimized local evidence

Before testing any workaround, I created and verified a local backup. SQLite PRAGMA quick_check returned ok.

At snapshot time:

• state_5.sqlite: 718 total thread rows
• 516 unarchived
• 202 archived
• After excluding internal subagent/guardian rows: 299 top-level conversations
• 102 unarchived top-level conversations
• 197 archived top-level conversations
• Unarchived top-level breakdown:
• 62 human/realtime/unspecified conversations
• 40 automation conversations
• Session rollout files:
• 516 under ~/.codex/sessions
• 202 under ~/.codex/archived_sessions
• session_index.jsonl: 302 named index rows before the current investigation updated it

The persisted database and rollout counts agree; this does not look like deletion.

Strong reproduction

1. Requesting the app-facing thread list with limit: 200 returns exactly 50 threads.
2. At the time of capture those 50 were:

• 1 active
• 18 idle
• 31 notLoaded

1. Searching by the exact known title of an older, unarchived local thread returns zero results.
2. Directly reading that same omitted thread by opaque ID succeeds and returns its historical turns.
3. The same direct-read test succeeds for an archived thread.
4. Recent desktop logs show thread/list completing successfully with errorCode=null, so this is not a sustained app-server transport failure.

This demonstrates that both list and search are operating over the recent 50-item projection rather than all persisted top-level threads.

Pin workaround result

I also tested pinning one known omitted, unarchived thread:

• the pin mutation succeeded in backend metadata;
• the thread still did not appear in the 50-item list;
• exact-title search still returned zero results;
• I immediately unpinned it afterward.

So pinning alone, without first resuming/opening the hidden thread, is not a reliable recovery method on this build.

Impact

This is causing real loss of discoverable working context across ongoing fabrication, application, repository, and operational projects. The data remains recoverable only if the user already knows the opaque thread ID or manually queries local SQLite/session files.

Expected behavior

• thread/list should honor pagination beyond 50.
• Sidebar search should query all persisted top-level threads, not only the hydrated recent set.
• Project/chronological views should page older active threads.
• Pinning an existing active thread should invalidate/rebuild the visible list.
• The app should provide a safe “All local threads” or “Rebuild thread index” action.

No raw logs, databases, private paths, titles, or thread IDs are attached publicly. Redacted diagnostics are available if maintainers request a specific subset.