Windows Desktop: sidebar/project list lost after update; search still finds threads; projectless-thread-ids workaround restores flat chats but project grouping remains broken

Open 💬 5 comments Opened Apr 27, 2026 by crmendi

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

Observed after two Desktop updates: - Earlier affected version in logs: OpenAI.Codex_26.422.2437.0_x64__2p2nqsd0c76g0 - Current affected version: OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0 - Packaged app-server process currently used by Desktop: C:\Program Files\WindowsApps\OpenAI.Codex_26.422.3464.0_x64__2p2nqsd0c76g0\app\resources\codex.exe app-server --analytics-default-enabled Global npm CLI was also checked: - Before: codex-cli 0.34.0 - Updated to: codex-cli 0.125.0 - But Desktop does not use the global npm CLI; it uses the packaged app\resources\codex.exe.

What subscription do you have?

ChatGPT Plus.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary
After updating Codex Desktop on Thursday, April 23, 2026, the left sidebar stopped showing my historical chats/projects.

The data is not lost:

Desktop search still finds the old chats.
state_5.sqlite still contains the threads.
session_index.jsonl still exists.
sessions still exists.
thread/list returns successfully with errorCode=null.
However:

The normal sidebar only showed 3 recent/projectless chats.
Projects were not restored in the sidebar.
Search results still showed old chats with their project labels.
A local workaround that rebuilt .codex-global-state.json -> projectless-thread-ids made all old chats visible again, but only as a flat Chats list, not grouped by project.
Reducing projectless-thread-ids back to the actual 3 projectless chats made all old project chats disappear again.
This strongly suggests the Desktop sidebar/project grouping is no longer being populated correctly from the existing local thread database and workspace hints.

What issue are you seeing?
After update, historical chats and projects disappeared from the left sidebar.

Expected:

Existing chats should remain visible in the sidebar.
Existing projects should remain visible/grouped.
Search and sidebar should agree on the same local thread set.
Project grouping should work from existing threads.cwd, thread-workspace-root-hints, or equivalent project state.
Actual:

Search finds old chats/projects.
Sidebar initially showed only 3 chats:
Fix chat list visibility
Corrige estado local tras update
Recupera proyectos y chats
Those 3 IDs exactly matched .codex-global-state.json -> projectless-thread-ids.
Rebuilding projectless-thread-ids with all 101 non-archived thread IDs made all chats visible, but flat under Chats.
Rebuilding thread-workspace-root-hints and adding historical workspaces to config.toml did not make project sections reappear.
Restoring projectless-thread-ids to only the 3 Documents\Codex generated/projectless threads hid the older project chats again.
Local evidence
Important local files:

C:\Users\user\.codex\state_5.sqlite
C:\Users\user\.codex\session_index.jsonl
C:\Users\user\.codex\sessions
C:\Users\user\.codex\.codex-global-state.json
C:\Users\user\.codex\config.toml
C:\Users\user\.codex\auth.json
Backup created before repair attempts:

C:\Users\user\Documents\Codex\2026-04-23\backup-codex-20260423-224608
Current thread database findings:

threads_total: 107
non_archived_threads: 101
archived_threads: 6
No thread rows had:

cwd = '~'
cwd LIKE '%~%'
All checked cwd paths existed.

Many historical thread cwd values use Windows extended path form:

\\?\C:\Users\user\...
Examples of redacted workspaces present in the DB:

C:\Users\user\OneDrive - redacted\Python\Web
C:\Users\user\OneDrive - redacted\Python\Revision pliegos\V2 APP
C:\Users\user\OneDrive - redacted\Python\App_Topologia
C:\Users\user\OneDrive - redacted\Documentos\Playground
C:\Users\user\OneDrive - redacted\Python\Contratos_Extreme\Extractor contratos
C:\Users\user\OneDrive - redacted\Python\Bot
C:\Users\user\Downloads\MCP
C:\Users\user\Downloads\Mindfull
Relevant .codex-global-state.json behavior
Before workaround:

"projectless-thread-ids": [
"019dbd91-c5bb-7fc1-8f6d-37bac0fa85af",
"019dbe43-32ce-73d1-9e04-593ae16dfd1e",
"019dcfb9-c254-7200-a2e9-dd4024aac53b"
]
Those were exactly the only 3 chats visible in the sidebar.

thread-workspace-root-hints existed only for those 3 initially.

After rebuilding projectless-thread-ids with all non-archived threads:

projectless-thread-ids: 101
thread-workspace-root-hints: 101
Result:

All old chats became visible again.
But all were shown as a flat Chats list.
Projects were still not separated/grouped in the sidebar.
After setting projectless-thread-ids back to only the 3 Documents\Codex generated/projectless threads while keeping 101 workspace hints:

projectless-thread-ids: 3
thread-workspace-root-hints: 101
Result:

Old project chats disappeared from the sidebar again.
Search still found them.
This suggests sidebar visibility currently depends on projectless-thread-ids, while project grouping is not being rebuilt from the DB/hints/config.

Logs
Desktop logs are under:

C:\Users\user\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs
thread/list succeeds:

method=thread/list
errorCode=null
Repeated Git/workspace worker error:

warning [git-origin-and-roots] Failed to resolve origin for workspace
errorMessage="ENOENT: path does not exist: ~"
The literal ~ was not found as an active cwd in state_5.sqlite, session_index.jsonl, or active .codex-global-state.json values. Occurrences of ~/local:~ in .codex-global-state.json appeared inside prompt-history, not active state.

Feature mismatch also appears repeatedly:

unsupported feature enablement workspace_dependencies
currently supported features are apps, memories, plugins, tool_search, tool_suggest, tool_call_mcp_elicitation
The UI logs show:

Features enabled = "... workspace_dependencies ..."
But the packaged app-server rejects that feature. Adding this to config.toml did not stop Desktop from trying to sync the feature:

[features]
workspace_dependencies = false
Other repeated warning:

No owner repo found for remote task
taskId=task_e_68958a87f4b8832582974f4af01f7c47
taskId=task_e_6894fff9c5588325b30149ccb2d18b83
Repair attempts already tried
Verified data exists:

state_5.sqlite
session_index.jsonl
sessions
auth.json
Backed up local Codex data.

Normalized old session rollout records:

Converted record_type:"state" to type:"state".
Added type:"session_meta" to old headers missing type.
Verified:
0 sessions with record_type.
0 sessions missing type.
Cleared recreatable Desktop cache/state under package directories:

LocalCache\Roaming\Codex
LocalCache\Local\Codex
Settings
TempState
Checked .codex-global-state.json for active ~ or local:~.

None found outside prompt-history.
Updated global npm CLI:

From codex-cli 0.34.0
To codex-cli 0.125.0
Confirmed workspace_dependencies stable true in global CLI.
Did not fix Desktop because Desktop uses packaged app\resources\codex.exe.
Added [features] workspace_dependencies = false to config.toml.

Did not stop Desktop UI from attempting to enable workspace_dependencies.
Created empty literal ~ directories in likely resolution locations as a workaround for ENOENT: path does not exist: ~.

Did not fix sidebar/project grouping.
Rebuilt .codex-global-state.json -> projectless-thread-ids with all non-archived thread IDs.

This restored chat visibility.
But project grouping was lost: all chats appeared flat under Chats.
Rebuilt thread-workspace-root-hints and added missing historical workspaces to config.toml.

Did not restore project grouping.
Reduced projectless-thread-ids back to only actual projectless Documents\Codex threads.

Old project chats disappeared again.
Search still found them.

What steps can reproduce the bug?

Minimal reproduction from current state
Use Codex Desktop on Windows.
Have historical threads in state_5.sqlite with project/workspace cwd values, many using \\?\C:\....
After Desktop update/restart, observe:
Search finds old chats/projects.
Sidebar only shows IDs present in .codex-global-state.json -> projectless-thread-ids.
Project/grouped sidebar entries do not populate from existing threads.cwd or thread-workspace-root-hints.
Manually add all non-archived thread IDs to projectless-thread-ids.
Restart Desktop.
Observe:
All chats appear.
They are not grouped by project.
Remove old project chats from projectless-thread-ids while keeping thread-workspace-root-hints.
Restart Desktop.
Observe:
Old project chats disappear again.
Search still finds them.

What is the expected behavior?

Expected behavior
Codex Desktop should rebuild or read project/sidebar grouping from durable local state:

state_5.sqlite -> threads
session rollout metadata
threads.cwd
thread-workspace-root-hints
trusted projects in config.toml
The sidebar should not depend on projectless-thread-ids to show historical project chats.

Project grouping should work even when Windows paths have equivalent forms:

C:\...
\\?\C:\...
OneDrive-backed paths

Additional information

Actual behavior
thread/list succeeds.
Search finds chats and project labels.
Sidebar project grouping is broken.
Sidebar visibility appears tied to projectless-thread-ids.
thread-workspace-root-hints with 101 entries is not enough to restore project sections.
Desktop repeatedly logs ENOENT: path does not exist: ~.
Desktop UI enables workspace_dependencies, but packaged app-server rejects it.
Related issues
This appears closely related to existing Windows/Desktop state and project grouping bugs:

https://github.com/openai/codex/issues/17540
Windows app: older local threads disappear while still present on disk. Similar state_5.sqlite, session_index.jsonl, sessions, and \\?\C:\... path signals.

https://github.com/openai/codex/issues/17304
Desktop project sidebar hides active threads after update/state drift. Related to project sidebar not showing active historical threads even though local state exists.

https://github.com/openai/codex/issues/18253
Project Timeline shows no history despite existing threads. Related to Windows path identity mismatch with OneDrive/junction/\\?\ prefix.

https://github.com/openai/codex/issues/13845
Windows Desktop passes raw \\?\C:\... cwd to tools/processes. Confirms a Windows path normalization issue in Desktop.

Impact
This makes Codex Desktop look like historical chats/projects were lost after update, even though the local data is still present.

The current workaround can restore visibility only as a flat chat list by stuffing all non-archived threads into projectless-thread-ids, but it does not restore project grouping.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

#19290
#19128

Powered by Codex Action

justalmostgreat · 3 months ago

Adding a macOS data point that looks closely related, with a slightly different local workaround.

Environment:

Codex Desktop on macOS
Local state files under ~/.codex/
Primary files involved: state_5.sqlite and .codex-global-state.json

Observed behavior:

The sidebar made it look like chats/projects were gone.
The underlying data was still present in state_5.sqlite.threads.
Search / direct local inspection could still find the historical threads.
Saved workspace roots still existed in .codex-global-state.json under electron-saved-workspace-roots and project-order.
The missing piece was that most saved projects had no entries in top-level thread-workspace-root-hints, so those directories appeared empty in the sidebar even though their threads still existed.

Important detail from repair attempts:

Mapping every recovered thread to one exact cwd made the target project appear to collapse into a single/sidebar-limited row.
Keeping each thread on its original/distinct threads.cwd, while setting thread-workspace-root-hints[thread_id] = <saved project root>, restored the project grouping for that target project.
For the other saved directories, adding hints for active threads whose threads.cwd exactly matched each saved workspace root restored their sidebar visibility.

Concrete local counts from the repaired macOS state:

15 saved workspace roots
15/15 saved roots had sidebar hint coverage after repair
327 active exact-root threads restored across saved roots
353 total thread-workspace-root-hints after preserving existing worktree/project mappings

I also published a small sanitized macOS diagnostic/repair utility here, in case it helps anyone inspect the same state shape locally: https://gist.github.com/justalmostgreat/a2df89bc0196793c9191de67cad5f772

The utility is conservative: dry-run by default, backs up .codex-global-state.json, does not modify SQLite, and warns users to quit Codex Desktop before applying because the live app can overwrite the state file from memory.

The pattern suggests the sidebar/project list should be able to rebuild or backfill thread-workspace-root-hints from durable local state, at least from:

state_5.sqlite.threads.id
state_5.sqlite.threads.cwd
.codex-global-state.json.electron-saved-workspace-roots
.codex-global-state.json.project-order
existing workspace labels / aliases

Expected behavior:

If a saved workspace root exists and non-archived threads have cwd matching that root, the sidebar should not show that project as empty just because thread-workspace-root-hints is missing or stale.
If a thread is from a Codex worktree, the app should preserve the distinct threads.cwd for row identity but use the saved root hint for project grouping, rather than forcing all rows to the same cwd.

This is not a proposed code patch, just a local-state finding that may help narrow the desktop/app-server grouping bug.

Stef9332 · 3 months ago

Adding another Windows data point that appears to match this issue.

On a recent Codex Desktop Windows build, saved project roots are visible in the sidebar, but multiple projects show No chats even though their local threads still exist. The flat Chats section can still reappear, so this does not look like data deletion.

High-level local checks:

SQLite state DB integrity is ok.
Unarchived local thread rows exist for affected project workspaces.
Session index entries and rollout JSONL files still exist.
App-server thread/list logs show rollout loading with parse errors: 0.

A local backup-first repair attempt confirmed that changing thread metadata is not a reliable fix for project grouping. One attempted JSONL metadata tweak made the live sidebar worse until rolled back, while the underlying files continued to parse cleanly.

This reinforces the same core pattern reported here: local thread data is intact and readable, but Desktop project/sidebar grouping is not being hydrated correctly from durable local state.

Musaabk11 · 1 month ago

Still reproducible on 2026-07-15 in a current Windows build.

Environment

Codex Windows MSIX package: 26.707.9981.0
ChatGPT.exe file version: 150.0.7871.115
Windows 11 Pro 10.0.26200 x64
ChatGPT Plus

Current regression evidence

Three saved local projects repeatedly disappear from the sidebar or lose their grouped chats after normal use/restart. One project is on a Drive-backed path and another affected project is on a normal local C: path, so this is not limited to a single storage provider.

The chats are not deleted and are generally not archived. They remain readable/openable by thread ID, and their project assignments remain present. The inconsistent state is visible in ~/.codex/.codex-global-state.json:

electron-saved-workspace-roots still contains all affected projects.
project-order repeatedly drops one affected saved project.
sidebar-project-thread-orders retains some project mappings but loses another project's entry.
thread-project-assignments still maps the missing chats to the correct projects.
pinned-thread-ids repeatedly resets from seven restored task IDs to only zero to two IDs.
A project's sidebar-project-expanded-v1-* state also disappears.

Repairing those keys in both the live state file and its .bak, unarchiving the tasks, and pinning them restores all three groups temporarily. The running app later serializes the inconsistent in-memory sidebar state again, and the projects/chats disappear.

Reproduction pattern

Add several local projects and create or assign multiple chats to them.
Expand the projects and pin the important chats.
Switch between projects, continue using the app, and restart/reopen it later.
One project disappears from the sidebar; other projects remain but lose their grouped chats or pins.
Inspect local state: saved roots and thread-project assignments remain intact, while sidebar order/pin/expanded keys have been dropped.

Expected

Saved projects, project grouping, expanded state, and pinned tasks should persist across normal app use and restarts. The sidebar should rebuild from the authoritative saved roots and thread-project assignments rather than treating missing visibility/order keys as deletion.

This still appears to be a sidebar-state persistence/indexing bug rather than chat data loss, but it repeatedly makes active project history look deleted. This report is related to #17540, #20833, #25084, and the behavior originally described here.

Musaabk11 · 1 month ago

Additional UI observation from the same reproduction:

Pinned tasks are rendered only in the global Pinned section and disappear from their original project group. When every task in a project is pinned, the project expands to No tasks, even though those tasks are still assigned to it. Unpinning the affected tasks immediately returned them to the correct project groups (3 / 1 / 3 chats in this reproduction).

This explains why pinning was not a safe visibility workaround and made the grouped-project symptom worse. It does not explain the original project/sidebar disappearance, but the app should ideally keep pinned tasks visible in their project too, or avoid showing the misleading No tasks state when assigned tasks exist in Pinned.