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

Summary

Codex Desktop currently makes older project conversations effectively disappear from the UI once they fall outside the global recent conversation window. This is not an edge case and it is not just cosmetic: it makes the Desktop app unreliable as a working memory for real projects.

In my daily use, any thread that has not been updated for about a week becomes impossible to find in the Desktop UI. After investigating locally, this is not because the data is deleted. The local session files and SQLite rows are still present. The problem is that Desktop appears to preload only a global recent set of conversations, then groups/searches only that already-loaded subset.

This is a serious UX regression. Users are led to believe their project history has been deleted or lost, while the data is still on disk and visible through lower-level storage/CLI paths. Please prioritize a real fix rather than requiring users to patch bundles, touch rollout mtimes, pin hidden threads, or manually query SQLite.

Environment

Platform: macOS, arm64
Codex Desktop observed: 26.429.30905 (CFBundleVersion 2345)
CLI observed: codex-cli 0.125.0
Date reproduced: 2026-05-05

I also inspected another local Codex app bundle (26.422.21459) and found the same recent-list behavior, so this does not appear to be a one-off local install issue.

Local evidence

Local persisted data is present:

~/.codex/sessions: 2014 rollout JSONL files
~/.codex/session_index.jsonl: 564 entries
~/.codex/state_5.sqlite: 1250 active thread rows

Using a conservative filter for human-visible direct conversations:

where archived = 0
  and agent_role is null
  and source in ('vscode', 'cli')

I get:

890 direct active local conversations
50 updated within the last 7 days
840 older than 7 days

The cutoff is extremely telling:

rank 50: 2026-04-28 13:13:24 local time
rank 51: 2026-04-27 20:12:58 local time

So the issue looks like "older than a week" only because my last week of usage produced exactly 50 newer conversations. Once a conversation drops from rank 50 to rank 51, it disappears from the Desktop project UI/search even though it still exists locally.

Example project-level impact with private paths redacted:

Project A: 447 active local conversations, 0 in top 50, newest rank 56 -> not findable in Desktop project UI
Project B: 24 active local conversations, 0 in top 50, newest rank 257 -> not findable in Desktop project UI
Project C: 8 active local conversations, 0 in top 50, newest rank 67 -> not findable in Desktop project UI

Telemetry from the Desktop app also matches this failure mode:

thread_count_loaded_recent: 54

while the local database has hundreds of active direct conversations. The extra 4 appear to be pinned/currently loaded threads on top of the hardcoded recent 50.

Code-path evidence from the Desktop bundle

The Desktop app bundle contains this recent-loader behavior:

refetchThreadList(...) {
  ...
  await this.listRecentThreads({ limit: 50 * this.pageCount, cursor: null })
  ...
}

loadNextThreadListPage(...) {
  ...
  await this.listRecentThreads({ limit: 50, cursor: this.nextCursor })
  ...
}

searchThreads(...) {
  // searches only this.conversationIds, i.e. the loaded recent subset
}

listRecentThreads(...) {
  return this.requestClient.sendRequest("thread/list", {
    limit,
    cursor,
    sortKey: this.sortKey,
    modelProviders: null,
    archived: false,
    sourceKinds: ...
  })
}

This means the project sidebar is effectively grouping a global recent subset, not loading the actual history for each project/workspace.

Expected behavior

The Desktop UI must not hide valid local project conversations just because they are outside the latest 50 global conversations.

Expected behavior should be:

When expanding/opening a project, query all local threads for that project/workspace root (cwd) with pagination.
Sidebar search should query all persisted local threads, not only recentConversationIds already loaded into memory.
The UI should clearly distinguish "no chats" from "older chats not loaded yet". The current behavior is misleading.
The recent window size should either be much larger or configurable as a temporary mitigation, but increasing 50 to another fixed small number is not the real fix.
Add a regression test with >50 local conversations across multiple projects where one project has no conversations in the global top 50 but still has valid local history.

Related issues / prior reports

This appears related to, and still reproducible despite, earlier reports:

Please do not treat this as solved while Desktop still depends on a global recent-50 preload for project history visibility. This bug seriously damages trust in the app because it makes real, persisted work history appear to vanish.

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

Codex Desktop project sidebar hides older workspace conversations despite existing local thread data #20833
macOS Desktop sidebar hides older local conversations despite existing thread state #20419
Codex Mac app hides unarchived local threads until they are messaged again #20959
Codex Desktop project sidebar omits older unarchived threads #20608
Windows Codex Desktop sidebar hides valid local project threads while SQLite and rollout files are intact #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

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.

@peterpeirce

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

@ashe0047

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

Six local projects and their existing chats were visible after recovery.
I created another local project and continued working normally.
I shut down Windows normally and started the computer again.
On the next launch, projects/chats disappeared from the Codex sidebar or projects showed No chats.
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:

The original global recent-50 projection still prevents reliable discovery of older project conversations.
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:

Build project history from an authoritative, paginated snapshot of all persisted user-visible threads, not a global recent subset.
Mark initial_build_complete only after every page has been consumed and committed.
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.
Keep subagent, automation, and managed-runtime threads from consuming the ordinary top-level conversation discovery window.
Search the persisted catalog, not only IDs already loaded into the sidebar.
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

Accumulate enough local conversations that a project's chats are outside the globally hydrated recent set.
Verify that the project still has active rows in state_5.sqlite and valid rows in local_thread_catalog.
Fully exit and reopen Codex Desktop in Projects mode.
Expand the affected project.
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:

A long-running local task remained active through 11:05 IST.
The goal was paused, project state was verified, local services were stopped, and macOS was restarted normally.
After restart, the task did not appear in the project/sidebar or recent-task listing.
The local rollout remained intact at approximately 109 MB.
Reading the task directly by its opaque ID succeeded and returned the correct Codex task and latest turn with status notLoaded.
Navigating directly to that ID successfully reopened the task.
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:

Pin any thread you must keep visible.
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).
Once it is open, pin it or update it so it stays inside the recent window.
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

@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

Requesting the app-facing thread list with limit: 200 returns exactly 50 threads.
At the time of capture those 50 were:
- 1 active
- 18 idle
- 31 notLoaded
Searching by the exact known title of an older, unarchived local thread returns zero results.
Directly reading that same omitted thread by opaque ID succeeds and returns its historical turns.
The same direct-read test succeeds for an archived thread.
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.

I’m seeing the same behavior in the current ChatGPT/Codex Desktop app.

Once all conversations in a project fall outside the globally loaded recent-conversation window, the project effectively disappears from the Projects UI, even though the project and its conversations still exist and can still be found/accessed manually.

This makes Projects unreliable as a persistent organizational feature, since older projects behave as if they were removed simply because they haven’t been active recently.

Would really appreciate a fix so project visibility is independent of the global recent-conversation limit.

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

Description

Summary

Environment

Local evidence

Code-path evidence from the Desktop bundle

Expected behavior

Related issues / prior reports

Activity

github-actions commented on May 5, 2026

studioetc commented on May 5, 2026

claell commented on May 6, 2026

studioetc commented on May 9, 2026

alferrante commented on May 11, 2026

gydx6 commented on May 12, 2026

bartmcdonough commented on May 13, 2026

bartmcdonough commented on May 13, 2026

miccTronic commented on May 13, 2026

ashe0047 commented on May 18, 2026

mgdark-commits commented on May 24, 2026

FrankZhangRp commented on May 25, 2026

13 remaining items

abhii-roy commented on Jun 17, 2026

ashe0047 commented on Jun 17, 2026

Necmttn commented on Jun 21, 2026

stephenbaugh commented on Jun 21, 2026

ashe0047 commented on Jun 23, 2026

moayadstar commented on Aug 2, 2026

Environment

User-visible sequence

Read-only diagnostic evidence

Expected behavior

Privacy

DrunkenAI commented on Aug 3, 2026

Environment

User-visible behavior

Read-only local evidence

Expected behavior

BradGroux commented on Aug 3, 2026

Summary

Durable-store evidence

Recent-window evidence

New catalog-layer evidence

Expected fix behavior

creamtea47 commented on Aug 10, 2026

Environment

Current symptom

Durable-state evidence

Stronger catalog-reader evidence

Reproduction

Expected behavior

damogallagher commented on Aug 12, 2026

naipi11 commented on Aug 18, 2026

creamtea47 commented on Aug 22, 2026

naipi11 commented on Aug 22, 2026

ReggieCarey commented on Aug 23, 2026

Environment

Privacy-minimized local evidence

Strong reproduction

Pin workaround result

Impact

Expected behavior

LiuHangyuWE commented on Sep 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions