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