Windows Desktop: Sidebar shows No chats and no projects after update, but Search can still find/open existing chats

What version of the Codex App are you using?

Codex CLI bundled with the app reports:

codex-cli 0.124.0-alpha.2

The executable metadata reports:

FileVersion: 0.124.0-alpha.2
ProductVersion: 0.124.0-alpha.2

I can provide the exact desktop app version from Help > About Codex if needed.

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows 11 x64

What issue are you seeing?

After the recent Codex Desktop update on Windows, the left sidebar no longer shows my chat history, pinned chats, local folders, or projects.

The sidebar shows:

Chats
No chats

I also cannot open local folders/projects from the normal sidebar/project flow.

However, the chat data is not gone. Search still works:

If I click Search, I can find the missing chats.
I can open existing chats from Search.
I tested one of the missing chats by sending a message saying test.
The message was accepted and the chat continued.
Even after sending that new message, the chat still did not appear under Chats in the left sidebar.

So this appears to be a sidebar/home/project listing problem, not total session data loss.

Local data still appears to exist on disk:

The local Codex sessions directory contains 33 rollout-*.jsonl files.
The local Codex session_index.jsonl exists and contains 60 indexed thread entries.
The index includes thread names updated on 2026-04-21, 2026-04-22, 2026-04-23, and 2026-04-24.
The local Codex state_5.sqlite exists and was recently updated.

Logs around startup show thread/list requests returning without an obvious request error, but the UI still renders an empty chat list. Logs also show this warning around the update/startup window:

[global-state] Failed to load global state errorMessage="Unterminated string in JSON at position 524288 (line 1 column 524289)"

What steps can reproduce the bug?

I do not have a clean deterministic repro yet. What happened:

Use Codex Desktop on Windows with existing chat history, pinned chats, local folders, and projects.
Install/restart after the recent Codex app update.
Open Codex Desktop.
Observe that the sidebar shows Chats -> No chats, with pinned chats, local folders, and projects missing.
Click Search.
Search can still find the missing chats.
Open an existing chat from Search and send a new message.
The chat remains absent from the left sidebar even after new activity.

What is the expected behavior?

Codex Desktop should continue showing existing chat history, pinned chats, local folders, and projects after an app update.

At minimum, if Search can still find and open a chat, that chat should also appear in the normal Chats sidebar list, especially after new activity in that chat.

Additional information

This may be related to prior history/session issues, but it seems broader than a single project timeline path mismatch:

The important part: this does not look like all local data was deleted. Existing chats remain discoverable and usable through Search. The failure appears specific to the sidebar/home/project listing and possibly pinned/project state.

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

Chats not displaying under project in sidebar #18187
threads / projects in sidebar missing #18640
Threads keep disappearing from the sidebar even with "All chats" selected #17970
Windows Codex Desktop rewrites threads.cwd to \\?\-prefixed paths on startup, splitting one workspace into two and hiding thread history #19128
Windows app: older local threads disappear from sidebar and sidebar search after restart while still present on disk #17540

Powered by Codex Action

I hit what looks like the same sidebar/project-listing class of bug, but on a larger local history.

Observed on Windows Codex Desktop with hundreds of local sessions:

state_5.sqlite still had 443 threads, 436 active.
.codex/sessions/.../rollout-*.jsonl files still existed.
Specific project folders such as older local workspaces appeared empty in the sidebar.
Direct codex.exe app-server probing showed thread/list supports nextCursor pagination and returns more data across pages.
The frontend state snapshot before patching showed far fewer recent threads loaded than existed in local history.

This made the problem look like data loss, but the sessions were still on disk and still addressable by app-server. The failure was in the recent-thread/sidebar loading path.

I documented a local Windows-only workaround here:

https://github.com/constansino/codex-desktop-session-limit-patch

The workaround does not mutate .codex/state_5.sqlite, does not reorder updated_at, and does not rewrite rollout files. It keeps the official WindowsApps install untouched, copies the app resources into a separate local directory, and patches the copied frontend bundle so the initial recent-thread load follows nextCursor for multiple pages. It also raises load-more/search page sizes and gives the patched window a separate title/userData path so it can coexist with the official app.

I think the upstream fix should be one of:

Auto-page the sidebar's recent-thread load until enough data is available for project grouping.
Add a user-configurable local sidebar/session history cap, for example 50 / 100 / 500 / 1000 / all.
Show a different UI state for "the list is not fully loaded yet" instead of making a folder look like it has no conversations.

This would avoid local repacking and make the behavior predictable for users with large local histories.

try this https://github.com/tonyabracadabra/codex-sidebar-project-repair

I hit a related local-history visibility issue after a Codex Desktop update and packaged the recovery workflow I used here:

https://github.com/huajiexiewenfeng/codex-session-recovery

This is an unofficial workaround, not an upstream fix. It is designed for cases where local session data still exists but the Desktop sidebar/project list cannot show it because local metadata, global project/sidebar state, SQLite cwd, or exact path matching is stale after an update.

The workflow dry-runs first, creates timestamped backups before writing, and verifies missing_* counts and cwd_exact_match_risk afterward.

Adding a Windows ARM64 data point on the new combined ChatGPT/Codex desktop build.

Environment

OpenAI.Codex package: 26.715.10079.0 (Windows ARM64)
Packaged app-server: 0.145.0-alpha.30
New combined ChatGPT/Codex desktop UI

Symptoms

Existing Codex tasks still open and remain usable.
The left sidebar stays at Work and shows Projects: No projects and Recent: No tasks.
Search/internal navigation can still find and open existing tasks.
App-internal project/thread APIs still return local projects and recent tasks.

Local evidence

state_5.sqlite passes PRAGMA integrity_check (ok).
Existing session rollout files are readable.
Startup uses hostId=local.
Multiple thread/list requests succeed with errorCode=null.
Rebuilding the current-version sidebar metadata (thread-project-assignments, thread-workspace-root-hints, sidebar-project-thread-orders, project-order, and projectless-thread-ids) survives a full restart, but the sidebar still renders empty.
No thread database rows or rollout files were modified.

This looks like a renderer/sidebar hydration regression in 26.715 rather than data loss or missing local metadata. I can provide a redacted diagnostic bundle if maintainers need it.

Update — I traced the root cause on my machine (26.715.10079.0, Windows ARM64).

My ChatGPT-mode tokens contain no chatgpt_account_id / chatgpt_user_id / chatgpt_plan_type in the https://api.openai.com/auth claim — only user_id, organizations, and chatgpt_data_residency / chatgpt_compute_residency. Reproduced with every login method (email + password, phone + device-code, clean browser profile).

The backend is fine with this: codex CLI on the same auth.json reports "Logged in using ChatGPT" and completes tasks on my subscription. But the desktop's client-side feature-access check resolves to denied / missing-account, which:

forces the "work" UI variant,
hides all codex content in the sidebar → permanent "No projects / No tasks" (while Search still works, since it doesn't go through this gate),
never starts local thread catalog population,
and remote-control enrollment keeps failing with -32603 waiting for a ChatGPT account id.

Expected behavior: either accept claim-less tokens like the backend does, or show an explicit "connect your ChatGPT account" notice instead of silently empty lists.

Additional reproduction on Windows (2026-07-24)

I reproduced the same issue across all saved local projects on a newer Windows build. This has a high-impact, data-loss-like presentation even though the sessions still exist.

Environment

Codex Windows app: 26.721.3404.0
Bundled CLI/app-server metadata observed in session records: 0.145.0-alpha.30
OS: Windows 10.0.26200 x64
Four saved local projects; every project group showed No tasks at the same time

Observed behavior and diagnostics

The saved-project inventory still returns all four projects correctly.
The sidebar/thread-list inventory returned only the newly opened current Codex task (plus unrelated ChatGPT history), but none of the earlier Codex project tasks.
Missing tasks can still be read directly by thread ID with complete conversation history.
Affected tasks report notLoaded; they are not archived. An explicit unarchive attempt returns no archived rollout found.
Durable local data is still present:
- 144 active session JSONL files
- 60 lines in session_index.jsonl
- 50 session JSONL files modified in the last two days
- 7 archived session JSONL files
A full Codex app restart did not restore the sidebar.
A just-finished hidden task had continued normally through build/tests/push, confirming that execution and session persistence were not lost.

Strong minimal probe / workaround

Pin one affected hidden task by thread ID.
It immediately reappears in the thread inventory with the correct local projectId and becomes visible in the sidebar.
Unpin the same task.
It immediately disappears from the inventory/sidebar again.
Keeping affected tasks pinned is currently the only reliable workaround I found.

This suggests the durable thread data and project resolution still work, but unpinned notLoaded local threads are being omitted from sidebar/list hydration.

Expected behavior

All unarchived local tasks should remain visible under their saved projects after restart, including notLoaded threads. If project/sidebar mapping state is stale or missing, Codex should rebuild it from durable local thread/session metadata.

Project paths, task titles, and conversation contents are intentionally redacted. I can provide a redacted screenshot, sanitized thread IDs, and targeted diagnostics if maintainers request them.

Additional Reproduction on Windows x64 — Version `26.721.3996.0`

I encountered the same issue after updating Codex Desktop for Windows.

Environment

OS: Windows x64
Codex Desktop version: 26.721.3996.0

Symptoms

The left sidebar shows:

Projects: No projects
Recent: No tasks

Additional observations:

Search can still find the missing local tasks.
The tasks can be opened and continued normally.
Sending new messages does not make them reappear in the sidebar.
The tasks are not archived.
Pinning an affected task does not make it appear.
Neither existing nor newly created local project tasks appear in the sidebar.

Evidence That the Data Is Intact

SQLite integrity check: ok
Active thread records: 188
Real user/project threads: 44
Service/subagent threads: 144
Current local sidebar state contains:
- local-projects: 7 entries
- thread-project-assignments: 52 entries
- sidebar-project-thread-orders: 4 entries
- projectless-thread-ids: 23 entries
Local thread/list requests complete successfully.
Session files and the local SQLite database remain readable.
Search can open the complete conversation history.

This appears to be a sidebar/catalog hydration or renderer problem rather than data loss.

Recovery Attempts

I tried all of the following without success:

Fully exiting and restarting the application multiple times.
Checking archived tasks.
Refreshing and toggling the sidebar.
Switching model providers.
Using Windows application Repair.
Re-registering or reinstalling the application.
Performing a clean uninstall and reinstall.
Recreating the application cache.
Rebuilding the current sidebar and project state:
- local-projects
- project-writable-roots
- thread-project-assignments
- sidebar-project-thread-orders
- thread-workspace-root-hints
- project-order
Rebuilding and validating session_index.jsonl.
Pinning an affected hidden task.

The rebuilt state survives a complete restart, but the sidebar still renders empty.

Possible Regression Area

The current desktop application contains the following local thread catalog modes:

disabled
populate_only
consume

The application code appears capable of disabling direct recent-history loading when the local thread catalog enters consume mode. If catalog population or hydration fails, this could result in an empty sidebar while Search continues to work.

This is only a hypothesis, but it matches the observed behavior.

Expected Behavior

All unarchived local tasks should remain visible under their saved projects after an update.

If the local thread catalog cannot be loaded, the application should fall back to thread/list or rebuild the catalog from state_5.sqlite, rather than displaying No projects / No tasks.

Privacy

Thread IDs, project paths, conversation contents, credentials, and database files have been intentionally omitted. I can provide sanitized logs or additional diagnostics if requested.

@etraut-openai

Follow-up on 26.721.3996.0: the silent empty sidebar is now replaced by an explicit access splash — thank you, this is the "show an explicit notice instead of silently empty lists" behavior I asked for above. 👍

One problem with the wording, though. I checked the bundle: the feature-access decision (sln) still returns reason: "missing-account" when the token carries no chatgpt_account_id / chatgpt_plan_type — which is exactly my case (password/phone-based Personal account, same root cause as #13007). But the splash rendered for that state reads:

You don't have access to Codex yet. Contact your admin to request access.

For a Personal workspace where the signed-in user is the owner, there is no admin to contact — the CTA is a dead end. That copy fits the workspace-disabled reason, not missing-account.

Suggestion: branch the splash copy by reason —

workspace-disabled → keep the "contact your admin" message.
missing-account → show "re-authenticate, or contact support" instead, since the token simply lacks the ChatGPT claims (the server-side gap tracked in [VS Code Extension] Requires re-login on every restart — JWT missing chatgpt_plan_type on ARM64 Windows #13007 / fixed for the core in Handle missing plan info for ChatGPT accounts #13072 but re-surfaced by this UI layer).

cc @etraut-openai

Additional Windows reproduction: project catalog disappeared while task history remained accessible

I encountered a similar issue on the Codex desktop app for Windows. The Projects section became empty and displayed No projects, even though the repository, local task history, and recent tasks were still present.

Environment

OS: Windows 11 x64
ChatGPT plan: Pro
Codex desktop app package: OpenAI.Codex_26.721.11231.0_x64
Codex command runner: 0.146.0-alpha.3.1
An update from package version 26.721.4979.0 to 26.721.11231.0 was observed during the same period.

Timeline

Around 2026-07-30 04:06:55 JST (2026-07-29 19:06:55 UTC), a Codex app package update was observed.
After restarting Windows and launching Codex, the app displayed what appeared to be an initial onboarding screen asking about my main area of interest.
After completing that screen, the Projects section displayed No projects.
The Recent section still contained existing tasks, and those tasks could still be opened and continued.
The affected Git repository remained present and intact on disk.

A Windows restart/bugcheck also occurred during the same general period. I have not established that Codex caused it, so I am reporting it only as timing information rather than claiming causality.

Actual behavior

The sidebar project catalog is empty.
No projects is displayed under Projects.
Existing tasks are still visible under Recent.
Existing tasks can also be found through search and opened normally.
Opening an existing task still restores the correct repository context.
Repository files and Git history have not disappeared.

Expected behavior

Projects that were registered before the restart/update should remain listed in the Projects section.

If the project catalog is lost or fails to migrate, Codex should be able to reconstruct it from surviving task/session metadata without deleting or invalidating existing task history.

Local-state checks

The following privacy-sanitized checks were performed after the issue occurred:

Session rollout JSONL files found: 82
SQLite database checked: state_5.sqlite
SQLite integrity check result: ok
.codex-global-state.json exists, but:
- local-projects contains 0 entries
- selected-project is null
The Git repository is intact.
Session files remain present.
Existing tasks can still be opened from Recent or search.
No repository corruption was detected.

This suggests that the repository and task history were not deleted. The missing sidebar entries appear more consistent with project-catalog state being reset, lost, or not migrated correctly.

Difference from another report in this issue

This may be slightly different from the state described in comment #5072754258.

In that report, local-projects reportedly still contained seven entries while the sidebar displayed no projects. In my case, the persisted global state itself contains an empty local-projects collection and a null selected-project.

This may indicate a separate reset or migration path rather than only a sidebar rendering or catalog-hydration problem.

Possible recovery and prevention improvements

It may be useful for Codex to:

Validate a migrated project catalog before replacing the previous state.
Preserve the previous catalog if migration or hydration produces an unexpectedly empty result.
Reconstruct missing project entries from surviving task/session metadata, including recorded working directories.
Provide an explicit Add existing project or Rebuild project catalog operation that does not affect task history.
Record a diagnostic event when a non-empty project catalog becomes empty during startup or migration.

I can provide additional privacy-sanitized timestamps, state counts, and targeted log excerpts if they would help diagnose the issue. I would prefer not to upload the raw rollout JSONL files, SQLite database, or complete global-state file because they may contain task content or local identifiers.

I have observed a related but slightly different low-frequency variant of this sidebar/history issue.

Observed behavior:

A single existing chat occasionally disappears from the normal chat/sidebar list.
The chat is still discoverable through Search and can be opened normally from the search result.
The conversation contents appear intact and the thread remains usable.
After sending a new message in that chat, it reappears in the normal sidebar/chat list.

This has happened only rarely, and I do not currently have a deterministic reproduction, logs, screenshots from the moment of disappearance, or enough evidence to identify the responsible layer. I therefore cannot confirm that it has the same root cause as this issue.

One potentially useful distinction from the reproduction in this issue: here, new activity appears to restore the missing chat to the sidebar, whereas the original report says that sending a new message did not restore it.

This may indicate a transient sidebar/list indexing or stale metadata state that is refreshed by a thread update, but that is only a hypothesis based on the observed behavior.

If it occurs again, I can try to capture the exact app version, thread state, screenshots, and relevant diagnostics before sending the message that makes the chat reappear.

Navigation Menu

Repository navigation

Windows Desktop: Sidebar shows No chats and no projects after update, but Search can still find/open existing chats #19290

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Additional reproduction on Windows (2026-07-24)

Environment

Observed behavior and diagnostics

Strong minimal probe / workaround

Expected behavior

Additional Reproduction on Windows x64 — Version `26.721.3996.0`

Environment

Symptoms

Evidence That the Data Is Intact

Recovery Attempts

Possible Regression Area

Expected Behavior

Privacy

Additional Windows reproduction: project catalog disappeared while task history remained accessible

Environment

Timeline

Actual behavior

Expected behavior

Local-state checks

Difference from another report in this issue

Possible recovery and prevention improvements

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Desktop: Sidebar shows No chats and no projects after update, but Search can still find/open existing chats #19290

Description

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Apr 24, 2026

constansino commented on May 1, 2026

tonyabracadabra commented on May 25, 2026

huajiexiewenfeng commented on May 31, 2026

Leilight commented on Jul 22, 2026

Leilight commented on Jul 23, 2026

suqinghechina-debug commented on Jul 24, 2026

Additional reproduction on Windows (2026-07-24)

Environment

Observed behavior and diagnostics

Strong minimal probe / workaround

Expected behavior

baejokerz-collab commented on Jul 24, 2026

Additional Reproduction on Windows x64 — Version 26.721.3996.0

Environment

Symptoms

Evidence That the Data Is Intact

Recovery Attempts

Possible Regression Area

Expected Behavior

Privacy

Leilight commented on Jul 24, 2026

caramelcase commented on Jul 30, 2026

Additional Windows reproduction: project catalog disappeared while task history remained accessible

Environment

Timeline

Actual behavior

Expected behavior

Local-state checks

Difference from another report in this issue

Possible recovery and prevention improvements

GuXinghai commented on Sep 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Additional Reproduction on Windows x64 — Version `26.721.3996.0`