Codex desktop loses local project registrations and hides active threads while CLI/core database remains healthy

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

• #33727
• #33771
• #33774
• #33652
• #33508

Powered by Codex Action

New reproduction: remote-availability failure causes thread/list failure

A further occurrence happened at approximately 2026-07-18T23:47:23Z.

• The local stdio Codex app-server initialized successfully in 289 ms.
• Local account and thread requests initially succeeded.
• remoteControl/enable returned successfully.
• Desktop secondary windows reconciled with persistedSelectedRemoteHostId=null but selected remote-ssh-discovered:pi-node1.
• Current global state was subsequently observed with selected-remote-host-id="remote-ssh-discovered:pi-node1".
• A remote-control environment remained in waiting-for-device / initializing.
• After 30.007 seconds its WebSocket app-server initialization failed with:

Codex app-server initialize handshake timed out

• The failure was propagated across the primary, hotkey-home, and hotkey-thread windows.
• A pending recent-threads thread/list request failed after 31.167 seconds with:

Codex app-server is not available

• The failing remote environment was then removed from the connection registry and disconnected.
• No new HTTP 401, auth_token_missing, or EPIPE event occurred during this reproduction.

This provides a direct connection between failed remote initialization and missing recent-thread/sidebar results: the local app-server remained healthy, but a thread-list request associated with the failing remote connection was rejected when that remote initialization timed out.

Please investigate why windows select pi-node1 when their persisted selection is null, why a failed remote-control environment is allowed to service or block recent-thread requests instead of falling back to Local, and why the UI reports this as “could not update remote availability.”

Sensitive remote environment, account, client, device-key, and request identifiers have been omitted.

I can reproduce the same failure on the current unified ChatGPT/Codex macOS app, with a more extreme catalog mismatch.\n\nEnvironment:\n- ChatGPT Desktop 26.715.61943 (build 5628)\n- Bundled Codex runtime 0.145.0-alpha.27\n- macOS 26.5.2, Apple Silicon\n\nSanitized diagnostics:\n- state_5.sqlite passes quick_check and contains 598 active threads.\n- App-server thread/list succeeds and returns current/recent threads, including newly created ones.\n- codex-dev.db passes quick_check, but local_thread_catalog contains only 8 stale rows; the newest catalog update is 2026-07-12.\n- local_thread_catalog_sync_state remains stuck at initial_build_complete=0, watermark_updated_at=NULL, and last_full_reconciled_at=NULL.\n- Dynamic config for the local thread catalog reports mode=disabled; the live-discovery fallback also renders an empty sidebar.\n- Newly created tasks never appear, so this is not limited to migration of old history.\n- Cmd+Q, sign-out/sign-in, workspace-hint backfill, and updating from 26.715.52143 to 26.715.61943 did not recover the sidebar.\n- A clean stable CLI in an isolated CODEX_HOME signs in and creates/lists tasks correctly, which further isolates the problem to Desktop sidebar/catalog hydration.\n\nI uploaded a private, transcript-free diagnostic report through the in-product feedback channel. Feedback ID: no-active-thread-019f83b0-a2b2-7622-a06b-95b317189f4e. No task contents, titles, raw databases, auth data, or browser tabs were included.\n\nThe product should fail open to the healthy thread/list result while the derived catalog is incomplete, and provide a supported catalog rebuild/reconciliation action.

I believe I am experiencing the same underlying defect, so I am adding my full reproduction timeline and sanitized diagnostics here instead of opening a separate issue.

Environment

• ChatGPT Business workspace
• macOS 26.5.2, build 25F84
• Apple Silicon
• Unified ChatGPT/Codex desktop app
• One large local Git project

I have also reported the problem through OpenAI Support.

Summary

After a ChatGPT Desktop update, many local Codex threads disappeared from the project sidebar and search.

The underlying threads, session files, SQLite records, Git repository and Git worktrees still exist and remain valid. The failure appears limited to the desktop project/thread catalog, project assignments, worktree associations or sidebar hydration.

The behavior has reproduced across multiple desktop-app updates, including with threads created after the original problem began.

Desktop-app version timeline

The issue persisted across these successive ChatGPT Desktop versions:

• 26.715.61943, build 5628
• 26.715.70719, build 5650
• 26.715.71837
• 26.715.72028
• 26.715.72359
• 26.721.31836, installed on July 24

Updating, fully quitting the app with Cmd+Q and reopening it did not restore the missing threads on any of these versions.

Initial loss

Immediately after the first affected update, the project still showed approximately 38 threads, although many older threads were already missing.

The project had previously contained substantially more local Codex activity.

The missing threads were not found through:

• exact title search;
• exact thread-ID search;
• chronological sorting;
• archived chats;
• app restart;
• sign-out and sign-in.

Removing and re-adding the project made the problem worse

As a non-destructive troubleshooting step recommended by Support, I removed the project from the sidebar and re-added the exact same local repository folder.

The confirmation dialog stated that only the sidebar project entry would be removed and that files on disk would not be deleted.

After re-adding the folder:

• the visible project-thread count dropped from approximately 38 to exactly 8;
• the missing threads did not return;
• the repository remained intact;
• the existing Git worktrees remained intact;
• the local session files remained present;
• the SQLite thread records remained present.

I have not removed or re-added the project again.

Newly created threads also disappear after an update

While running ChatGPT Desktop 26.715.72028, I created three new standalone read-only threads in separate new worktrees.

Before the next update, the project showed 11 visible threads:

• the 8 older threads that had remained visible;
• plus the 3 newly created threads.

After updating from 26.715.72028 to 26.715.72359 and restarting the app:

• the visible count returned from 11 to 8;
• all three newly created threads disappeared from the project sidebar;
• the three threads were also absent from desktop search.

A later update to 26.721.31836 did not restore them. The project still shows only 8 threads.

This demonstrates that the issue is not limited to migration of older history. Threads created after the original failure can also disappear during a subsequent desktop-app update.

Local thread audit

I performed a read-only audit of the local Codex data.

Results:

• 117 unique thread IDs were identified for this project;
• 112 were strong metadata-path matches, where session metadata directly referenced the repository or one of its worktrees;
• the missing threads remain present in the local session index;
• their rollout JSONL session files remain present;
• the main Codex SQLite database is valid;
• PRAGMA integrity_check returns ok;
• the affected thread rows remain present in the threads table;
• the affected rows have archived=0;
• their current titles are present;
• their rollout paths are present;
• their cwd values point to the expected worktrees.

No session, index or database files were modified during this audit.

Comparison between persistent and newly disappearing threads

The three newly disappearing threads were created using embedded Codex runtime:

• 0.145.0-alpha.30

The eight older threads that continued to remain visible were originally created using:

• 0.145.0-alpha.18

This does not prove that the runtime change is the direct cause, but it is a consistent boundary in this dataset.

For each of the three newly disappearing threads:

• the session-index record exists;
• the rollout file exists;
• the SQLite threads row exists;
• archived=0;
• the current renamed title is stored correctly;
• the cwd points to the correct Codex worktree;
• the worktree remains registered in Git;
• the worktree directory exists;
• Git resolves the worktree correctly;
• HEAD is the expected commit;
• the worktree is clean.

The missing threads therefore are not explained by deleted, corrupt or unregistered worktrees.

Git worktree verification

The affected worktrees are still returned by:

git worktree list --porcelain

For each affected worktree:

• the .git pointer is valid;
• git rev-parse --show-toplevel succeeds;
• git rev-parse HEAD returns the expected commit;
• git status --short is empty;
• all checks return exit code 0.

No branches or worktrees were removed.

Desktop versus Remote catalog mismatch

The visible thread catalogs also differ across ChatGPT surfaces.

Mac desktop

• shows only 8 threads for the project;
• does not show the newly created threads;
• cannot find them through search.

iPhone Remote

• shows a larger but older subset of the project history;
• does not show the newly created threads.

iPad Remote

• shows the same older subset as the iPhone;
• also does not show the newly created threads.

Restarting the mobile apps did not change the Remote list.

This suggests that:

• Mac desktop is using one incomplete local catalog;
• iPhone and iPad Remote are using another older shared catalog;
• neither catalog represents the complete healthy local thread database.

Non-destructive troubleshooting already completed

I have already tested:

• chronological sidebar sorting;
• archived chats;
• exact-title search;
• exact thread-ID search;
• fully quitting with Cmd+Q;
• reopening the app;
• signing out and signing back in;
• confirming the correct ChatGPT Business workspace;
• multiple desktop-app updates;
• removing and re-adding the project once, following Support instructions;
• Worktrees settings;
• Codex workspace diagnostics;
• repository validation;
• Git-worktree validation;
• SQLite integrity validation;
• session-index validation;
• rollout-file validation;
• comparison between visible and missing thread records.

None of these restored the missing threads.

The suggested model-training/history toggle cannot be enabled in this Business workspace because model training is automatically disabled for ChatGPT Business.

Backups and safety

I created multiple complete backups of the local Codex directory before continuing the investigation.

The latest verified backup contained:

• 17,402 source files;
• 17,402 copied files;
• approximately 1.3 GB of data.

I have not:

• reset the app;
• reinstalled ChatGPT;
• modified or replaced the SQLite database;
• modified the session index;
• modified rollout JSONL files;
• deleted or renamed sessions;
• deleted worktrees;
• recreated the missing tasks;
• manually repaired project, catalog or assignment metadata.

Actual behavior

• Active, unarchived threads exist in the core database but are absent from the desktop sidebar and search.
• Re-registering the same project can reduce the number of visible threads further.
• Newly created threads can disappear after the next desktop-app update.
• Existing valid worktrees can remain intact while the UI no longer associates them with their threads.
• Mac desktop, iPhone Remote and iPad Remote can display different incomplete subsets of the same project history.
• Repeated app updates do not rebuild or reconcile the missing associations.

Expected behavior

• Every active, unarchived thread in the healthy local thread database should remain discoverable.
• App updates should preserve local project registrations and thread-to-project/worktree associations.
• Re-adding the same repository should reconcile existing threads rather than produce a smaller catalog.
• Threads without a valid project assignment should appear in a chronological or unassigned fallback view.
• The app should provide a supported, non-destructive catalog rebuild or reconciliation action.
• When a derived desktop catalog is incomplete, the UI should fall back to the healthy core thread-list result instead of hiding valid threads.

Working hypothesis

The evidence is consistent with the core Codex thread database remaining healthy while one or more derived desktop structures become stale or incomplete:

• local thread catalog;
• local project registry;
• project ordering;
• thread-to-project assignments;
• thread-to-worktree associations;
• desktop sidebar hydration or reconciliation state.

The desktop app appears to reload or rebuild only an incomplete subset after certain updates, leaving valid active threads without a visible UI bucket.

The fact that threads newly created after the original incident also disappear after a subsequent update suggests that this is an ongoing catalog or association persistence problem, not only a one-time migration failure.

Additional macOS datapoint with the same core-store / Desktop-catalog divergence.

Environment:

• Codex Desktop: 26.721.41059 (build 5848)
• Bundled app-server/CLI: 0.146.0-alpha.3.1
• macOS 26.5.1, arm64
• Default CODEX_HOME (~/.codex); no custom CODEX_HOME
• Official signed app; only the current ChatGPT/Codex app was running
• 111 GiB free; ownership/permissions normal

User-visible behavior:

• After updates/restarts, some recent or still-relevant local project threads disappear from the project sidebar.
• The user did not archive them.
• For one affected local project, only a later thread remains visible while earlier threads for the same cwd are absent.
• Direct reads by exact thread ID work.
• Navigating/resuming a hidden thread succeeds, but it still does not re-enter the sidebar list.

Read-only diagnostics:

• ~/.codex/state_5.sqlite: 374 thread rows, 1 archived
• PRAGMA quick_check: ok
• Rollout referential check: 374/374 referenced rollout files exist, 0 missing
• ~/.codex/sqlite/codex-dev.db: PRAGMA quick_check = ok
• local_thread_catalog: 87 rows total and appears stale; its newest project rows stop well before current threads
• local_thread_catalog_sync_state for host_id='local':
• initial_build_complete = 0
• watermark_updated_at = NULL
• last_full_reconciled_at = NULL
• observation_sequence = 455
• Affected project:
• core threads: 20 active rows
• local_thread_catalog: 0 rows
• session_index.jsonl contains the affected thread IDs.
• Desktop thread/read and thread/resume succeed for a hidden ID.
• Renderer logs then show Conversation state not found for the same ID in non-primary windows.

Interpretation:
This is not transcript loss or archiving. The core thread database and rollout store are intact, while the Desktop local thread catalog has never completed its initial build and is not reconciling current threads. Updates/restarts appear to expose the stale catalog, causing active/recent threads to disappear from normal project discovery.

No database or cache repair was attempted, because related reports indicate rebuilding codex-dev.db does not resolve the stuck catalog sync and risks user state. I can provide further sanitized counts/timestamps privately if useful.

Additional macOS datapoint for the same core-store/Desktop-catalog divergence.

Environment:

• ChatGPT Desktop 26.803.41515 (build 6321)
• Bundled Codex runtime 0.147.0-alpha.6.5; standalone CLI 0.147.0
• macOS 26.5.2, arm64
• Sidebar organization: By project; chat sort: Priority

User-visible behavior:

• The current active thread stays at the top of the projectless list even though it was created in a saved local project; other chats from that project are not grouped consistently with it.
• The global desktop state assigns the current thread to a local project and does not list it in projectless-thread-ids or pinned-thread-ids.

Read-only diagnostics:

• state_5.sqlite: PRAGMA quick_check = ok; 1,361 thread rows; 57 rows for the current project checkout, 56 unarchived.
• codex-dev.db: PRAGMA quick_check = ok; local_thread_catalog has 16 rows, 0 for the current project checkout.
• local_thread_catalog_sync_state: initial_build_complete=0, watermark_updated_at=NULL, last_full_reconciled_at=NULL.

This suggests the UI is using an incomplete/stale derived catalog or assignment projection and treating a durably assigned thread as projectless. The global state also contains two saved local project registrations for sibling checkouts with the same project name; that may be an aggravating path/ID-resolution factor, but I have not established it as causal.

No Codex state, transcript, database, or raw log was modified or attached. This appears to be a variant of the existing project-assignment/catalog hydration failure rather than data loss.

### Codex version ChatGPT desktop: 26.715.31925 (build 5551) Embedded Codex runtime: 0.145.0-alpha.18 Standalone Codex CLI: 0.144.6 ### Environment macOS 27.0 (26A5378n), Apple Silicon Local project: /Users/tucker/projects/chatgpt Sidebar mode: Project, priority sorting ### Summary Throughout July 18, local projects and active threads repeatedly disappeared from the Codex desktop sidebar. The affected threads were not deleted: they remained active and unarchived in ~/.codex/state_5.sqlite, retained their rollout files, and could be resumed with the Codex CLI. This appears to be a synchronization failure between the core thread database, the desktop local-thread catalog, and the desktop project/sidebar state. Feedback and diagnostics were uploaded from thread: 019f7754-3609-7521-b6c6-a401f1788304 Primary affected thread: 019f76fb-159b-7841-978d-59551f1d7f02 — “Review CDRL Workflow Compatibility” ### Expected behavior Active, unarchived threads remain visible in the sidebar. Registered local projects persist across app restarts and host refreshes. An active thread without project assignment metadata appears in a chronological or projectless fallback view. Resuming an existing thread reconnects to it instead of creating a duplicate. ### Actual behavior The local project disappeared from the project list. Projects that remained visible showed “No chats.” The affected thread disappeared from the UI while it was still running. codex resume 019f76fb-159b-7841-978d-59551f1d7f02 could resume it. Recovery produced a second thread with the same title and cwd: 019f774e-e553-79c2-aa8e-284af891964f. There is no parent/fork edge connecting it to the original. ### Diagnostic evidence Both standalone and embedded codex doctor reported 17 ok | 1 idle | 0 warn | 0 fail; core database and rollout inventory agree. At final capture, the core database contained 70 active/unarchived threads (65 with previews), while the desktop local-thread catalog contained only 38 rows. The desktop catalog contained only one row for the affected cwd. Every host in local_thread_catalog_sync_state had initial_build_complete=0. An approximately 02:58 ET sidebar-state snapshot contained 17 local projects and 22 project-order entries. Later/current state contained 7 local projects and 6 project-order entries. Eleven prior local projects disappeared. The affected project was absent from both local-projects and project-order. The original thread had no thread-project-assignments entry, projectless assignment, or workspace-root hint, leaving it with no UI bucket in Project mode. The core DB record continued updating after CLI recovery while its session-index timestamp remained unchanged. The desktop log showed 97 successful thread/list responses and one transient failure, so this was not a sustained local app-server outage. Startup selected remote-ssh-discovered:pi-node1 even though the persisted selected host was null. The remote-control environment then logged 143 handshake failures and 142 reconnect attempts. macOS generated two disk-write resource diagnostics for the embedded Codex process: approximately 8.6 GB dirtied over 5,057 seconds early in the day, and approximately 2.1 GB over 5,877 seconds later. Samples include SQLite WAL/checkpoint and plugin-catalog cache writes. No Codex/ChatGPT crash report was found. ### Timeline ~03:01 ET: first excessive disk-write diagnostic. 14:08–14:09 ET: missing-thread and state-database discrepancy warnings; UI showed “No chats.” 14:12 ET: confirmed the issue existed before updating the standalone CLI. 14:13–14:19 ET: after the problem began, user-authorized cleanup/hydration of archived rows and session index was attempted, followed by an app restart. The visibility problem persisted. 15:45 ET: repeated read_repair_rollout_path: upsert_needed (slow path). 16:38 ET: ChatGPT launched and auto-selected the remote SSH host. 16:46 ET: primary affected thread created. ~17:50 ET: desktop activity for the original thread stopped. 18:16 ET: second disk-write diagnostic. 18:18 ET: duplicate thread created. 18:23 ET: macOS displayed “Dock Tile Extension Added — ChatGPT added 1 Dock tile extension.” This is included as correlated timing only; there is no evidence it caused the catalog failure. 18:25 ET: global sidebar state was atomically rewritten with the substantially smaller project registry. The manual database/session-index repair attempts occurred after the missing-thread symptom and are not the initial cause. ### Reproduction The issue is intermittent: 1. Open ChatGPT/Codex desktop in Project sidebar mode. 2. Open a local project and start or continue a long-running thread. 3. Allow an app restart/update, host refresh, or remote-host reconnection. 4. The project or thread may disappear, or the project may show “No chats.” 5. Resume the supposedly missing thread by ID with the CLI. 6. The thread remains active in the core database while its desktop project/assignment/catalog metadata is absent. ### Questions Why can local-projects, project-order, thread assignments, and local_thread_catalog diverge from state_5.sqlite? Why does the catalog remain at initial_build_complete=0 without rebuilding or self-repairing? Why are active orphaned threads not surfaced in a chronological/projectless fallback view? Why did recovery create a duplicate session rather than reattach the original? Can automatic stale remote-host selection alter catalog ownership or reconciliation? Are the excessive SQLite and plugin-catalog writes related? * Is there a supported way to rebuild the sidebar catalog without deleting transcripts? Full diagnostics and logs were uploaded through /feedback under thread ID 019f7754-3609-7521-b6c6-a401f1788304. Sensitive raw logs and databases are intentionally not attached publicly.

### Codex version ChatGPT desktop: 26.715.31925 (build 5551) Embedded Codex runtime: 0.145.0-alpha.18 Standalone Codex CLI: 0.144.6 ### Environment macOS 27.0 (26A5378n), Apple Silicon Local project: /Users/tucker/projects/chatgpt Sidebar mode: Project, priority sorting ### Summary Throughout July 18, local projects and active threads repeatedly disappeared from the Codex desktop sidebar. The affected threads were not deleted: they remained active and unarchived in ~/.codex/state_5.sqlite, retained their rollout files, and could be resumed with the Codex CLI. This appears to be a synchronization failure between the core thread database, the desktop local-thread catalog, and the desktop project/sidebar state. Feedback and diagnostics were uploaded from thread: 019f7754-3609-7521-b6c6-a401f1788304 Primary affected thread: 019f76fb-159b-7841-978d-59551f1d7f02 — “Review CDRL Workflow Compatibility” ### Expected behavior Active, unarchived threads remain visible in the sidebar. Registered local projects persist across app restarts and host refreshes. An active thread without project assignment metadata appears in a chronological or projectless fallback view. Resuming an existing thread reconnects to it instead of creating a duplicate. ### Actual behavior The local project disappeared from the project list. Projects that remained visible showed “No chats.” The affected thread disappeared from the UI while it was still running. codex resume 019f76fb-159b-7841-978d-59551f1d7f02 could resume it. Recovery produced a second thread with the same title and cwd: 019f774e-e553-79c2-aa8e-284af891964f. There is no parent/fork edge connecting it to the original. ### Diagnostic evidence Both standalone and embedded codex doctor reported 17 ok | 1 idle | 0 warn | 0 fail; core database and rollout inventory agree. At final capture, the core database contained 70 active/unarchived threads (65 with previews), while the desktop local-thread catalog contained only 38 rows. The desktop catalog contained only one row for the affected cwd. Every host in local_thread_catalog_sync_state had initial_build_complete=0. An approximately 02:58 ET sidebar-state snapshot contained 17 local projects and 22 project-order entries. Later/current state contained 7 local projects and 6 project-order entries. Eleven prior local projects disappeared. The affected project was absent from both local-projects and project-order. The original thread had no thread-project-assignments entry, projectless assignment, or workspace-root hint, leaving it with no UI bucket in Project mode. The core DB record continued updating after CLI recovery while its session-index timestamp remained unchanged. The desktop log showed 97 successful thread/list responses and one transient failure, so this was not a sustained local app-server outage. Startup selected remote-ssh-discovered:pi-node1 even though the persisted selected host was null. The remote-control environment then logged 143 handshake failures and 142 reconnect attempts. macOS generated two disk-write resource diagnostics for the embedded Codex process: approximately 8.6 GB dirtied over 5,057 seconds early in the day, and approximately 2.1 GB over 5,877 seconds later. Samples include SQLite WAL/checkpoint and plugin-catalog cache writes. No Codex/ChatGPT crash report was found. ### Timeline ~03:01 ET: first excessive disk-write diagnostic. 14:08–14:09 ET: missing-thread and state-database discrepancy warnings; UI showed “No chats.” 14:12 ET: confirmed the issue existed before updating the standalone CLI. 14:13–14:19 ET: after the problem began, user-authorized cleanup/hydration of archived rows and session index was attempted, followed by an app restart. The visibility problem persisted. 15:45 ET: repeated read_repair_rollout_path: upsert_needed (slow path). 16:38 ET: ChatGPT launched and auto-selected the remote SSH host. 16:46 ET: primary affected thread created. ~17:50 ET: desktop activity for the original thread stopped. 18:16 ET: second disk-write diagnostic. 18:18 ET: duplicate thread created. 18:23 ET: macOS displayed “Dock Tile Extension Added — ChatGPT added 1 Dock tile extension.” This is included as correlated timing only; there is no evidence it caused the catalog failure. 18:25 ET: global sidebar state was atomically rewritten with the substantially smaller project registry. The manual database/session-index repair attempts occurred after the missing-thread symptom and are not the initial cause. ### Reproduction The issue is intermittent: 1. Open ChatGPT/Codex desktop in Project sidebar mode. 2. Open a local project and start or continue a long-running thread. 3. Allow an app restart/update, host refresh, or remote-host reconnection. 4. The project or thread may disappear, or the project may show “No chats.” 5. Resume the supposedly missing thread by ID with the CLI. 6. The thread remains active in the core database while its desktop project/assignment/catalog metadata is absent. ### Questions Why can local-projects, project-order, thread assignments, and local_thread_catalog diverge from state_5.sqlite? Why does the catalog remain at initial_build_complete=0 without rebuilding or self-repairing? Why are active orphaned threads not surfaced in a chronological/projectless fallback view? Why did recovery create a duplicate session rather than reattach the original? Can automatic stale remote-host selection alter catalog ownership or reconciliation? Are the excessive SQLite and plugin-catalog writes related? * Is there a supported way to rebuild the sidebar catalog without deleting transcripts? Full diagnostics and logs were uploaded through /feedback under thread ID 019f7754-3609-7521-b6c6-a401f1788304. Sensitive raw logs and databases are intentionally not attached publicly.

Workaround: restoring missing Codex Projects on Windows without losing sessions

I managed to recover all my missing Codex Projects on Windows.

In my case, after updating Codex Desktop, almost all Projects disappeared from the sidebar. Re-adding the project folders did not restore the old chats, and downgrading Codex did not fix the issue either.

The important part is that the sessions were never actually lost.

Running:

codex doctor --summary

showed:

state databases healthy
threads rollout files and state DB thread inventory agree

I still had 318 .jsonl session files under:

%USERPROFILE%\.codex\sessions

What was actually broken

The problem was in:

%USERPROFILE%\.codex\.codex-global-state.json

My file had been reduced to approximately:

local-projects: 1
thread-project-assignments: 1

even though I had hundreds of existing sessions belonging to dozens of different project directories.

Each session .jsonl still contained valid metadata including:

{
"type": "session_meta",
"payload": {
"id": "...",
"cwd": "C:\\path\\to\\project"
}
}

So the information required to reconstruct the Projects was still available.

What fixed it

I rebuilt only these parts of .codex-global-state.json:

• local-projects
• project-order
• thread-project-assignments
• the existing workspace-root arrays where applicable

The reconstruction groups existing sessions by their payload.cwd.

For every unique existing project directory, I created a new local Project and associated every thread having that cwd with the new Project ID.

For example:

"thread-project-assignments": {
"THREAD_UUID": {
"projectKind": "local",
"projectId": "PROJECT_UUID",
"cwd": "C:\\path\\to\\project",
"pendingCoreUpdate": false
}
}

I first tested this manually with one missing Project.

That Project immediately reappeared in the Codex sidebar with all 10 of its old chats.

I then automated the same reconstruction for the remaining Projects, and all my missing Projects and their chats came back.

Important observations

I did not need to modify:

state_5.sqlite
session JSONL files

I also tried downgrading Codex before discovering this, and the downgrade did not restore the Projects.

So at least in my case this was not session corruption and not a database corruption issue.

It looks like Codex Desktop lost or reset the Project metadata stored in .codex-global-state.json, while the actual threads remained intact.

Also worth checking Windows path normalization when reconstructing the mapping:

C:\path\to\project

vs.

\\?\C:\path\to\project

I normalized those paths before grouping sessions.

Strong recommendation before attempting recovery

Make a complete backup of:

%USERPROFILE%\.codex

before modifying anything.

Do not delete the .jsonl sessions or state_5.sqlite if codex doctor reports that the database and rollout inventory are healthy.

If OpenAI adds an official “Rebuild/Reindex Projects from existing sessions” function, I think it could solve this failure mode automatically, since the necessary thread ID → cwd information is already present in the existing session metadata.

Thank you so much, josush1! I pasted a link to this thread and your workaround into Codex and asked it to fix itself. It wrote itself a little program to fix itself and all my projects are back! Thank you!