Codex Desktop update lost project/sidebar conversation history mapping although local sessions still exist

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

• #25084
• #26031
• #25924
• #25092
• #26104

Powered by Codex Action

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 can reproduce a very similar issue on macOS after today's ChatGPT/Codex desktop update.

Version / build:

• ChatGPT.app: 26.721.30844
• CFBundleVersion: 5813
• macOS desktop app

Observed behavior:

• The left sidebar Codex "Recent" section shows "No tasks" / no task entries.
• Existing tasks are still available through the task search popup; search shows both unfinished and completed tasks across projects such as apex/friend/admin.
• Pinning a task does not make it appear in the sidebar either.
• The local task index is still intact: the app-level task listing API can return the existing tasks, including recent active/idle/notLoaded tasks, so this does not look like data deletion.
• Some tasks have a saved project association, while others are projectless, but the sidebar fails even for the general recent/pinned visibility path.

This started after updating today; the same sidebar/project task list was working yesterday. The behavior looks like a regression in the sidebar/project task-list filtering or thread-to-project mapping layer rather than missing session data.

I can reproduce the same underlying failure on Windows, with one useful distinction from the recent macOS reports: the task is omitted by the app-level task-list API itself, not only by the rendered sidebar.

Environment:

• ChatGPT/Codex desktop: 26.721.4979.0
• Bundled Codex CLI: 0.146.0-alpha.3.1
• Windows NT 10.0.26200.8875 x64

Observed behavior:

• One completed local root task is absent from the sidebar/recent list.
• list_threads(limit=50) skips that task even though it returns both newer and older tasks from the same workspace.
• The task is not archived; its rollout remains under ~/.codex/sessions.
• session_index.jsonl contains the exact task ID, title, and an updated_at entry.
• A direct read_thread(threadId, hostId="local") succeeds and returns the complete task, including its final answer.
• Opening codex://threads/<thread-id> or navigating directly by task ID opens the task successfully in Codex Desktop.

This establishes that the conversation is intact and loadable, while enumeration/index projection is dropping it.

One potentially useful clue: the session-index timestamp corresponds to the beginning of the task, while the directly read task metadata correctly reports completion roughly 3 hours 19 minutes later. The affected task was a long GPT-5.6 Sol Ultra run with multiple compactions and delegated subagents.

Expected behavior:

• Any non-archived task present in session_index.jsonl and readable by ID should be returned by list_threads and appear under the documented Chronological task view.
• If an index projection is stale, Codex Desktop should rebuild it from the durable session metadata.

No local paths, source contents, prompts, or full session logs are included here. I can provide the affected task ID or redacted metadata privately if maintainers need it.

— GPT-5.6 Sol High

Adding a current macOS data point that isolates the project-assignment/sidebar layer from path-migration problems.

Environment:

• Codex Desktop: 26.727.51351 (build 6119)
• Bundled CLI: codex-cli 0.146.0-alpha.9.2
• Platform: macOS arm64
• Storage: default ~/.codex

All checks were read-only. Project names, absolute paths, titles, messages, and thread IDs are redacted.

What is intact

The primary store is internally consistent:

state_5.sqlite integrity: ok
total rows:               1,898
active rows:              1,867
archived rows:               31

active rollout files:     1,867
archived rollout files:      31

An older hidden conversation can still be read directly by its known ID. The app returns it as notLoaded, not missing or corrupt.

Exact project-mapping mismatch

The affected saved project still exists, its root has not moved, and the stored project root exactly matches the cwd on the historical thread rows. This is therefore not a path-normalization or deleted-folder case.

For one sanitized affected project:

primary database rows at exact project cwd:
  active rows:                   65
  active direct conversations:  42

global Desktop project state:
  explicit thread assignments:   2
  sidebar thread-order IDs:       1

The single sidebar ID is the newly opened current conversation. Older rows with the same exact cwd were not backfilled into that project.

Across the complete local state:

saved local project objects:           28
legacy saved workspace roots:          21
active primary thread rows:         1,867
thread-project-assignment entries:     208
projects with sidebar thread orders:     8

These counts do not prove that every historical row requires a permanent explicit assignment, but they do prove that the rendered project history cannot rely on those sparse caches without falling back to durable thread metadata.

Current catalog sync is also incomplete

The newer app-level catalog at ~/.codex/sqlite/codex-dev.db passes its integrity check, but it does not contain the affected project cwd at all:

local_thread_catalog rows:            109
distinct cwd values:                   10
initial_build_complete:                 0
watermark_updated_at:                NULL
last_full_reconciled_at:             NULL
observation_sequence:                 899

Its newest source update is from July 17, while valid primary-store threads continue through August 3.

The observed behavior is therefore:

1. Durable thread rows and rollout files remain healthy.
2. The saved project and exact cwd association remain valid.
3. The explicit project/sidebar mapping contains only newly observed threads.
4. The catalog cold-start/backfill is incomplete and has no watermark.
5. Opening a new conversation adds that conversation to the project but does not recover older same-cwd history.

Requested behavior

The project/sidebar state should be treated as a rebuildable projection, not the authority for whether history exists.

A safe recovery path should:

1. Canonicalize each saved project root and match all persisted thread cwd values during a full paginated backfill.
2. Use exact-cwd/root containment as a fallback when an explicit assignment is absent.
3. Merge existing explicit assignments instead of discarding them.
4. Populate sidebar order from the rebuilt project catalog, ordered by persisted recency.
5. Persist a watermark and completion marker only after the full snapshot succeeds.
6. Automatically retry or reconcile whenever initial_build_complete = 0 or the watermark is null.
7. Provide a supported UI/CLI action to rebuild project/thread mappings without editing .codex-global-state.json or SQLite manually.

Manual edits are not a durable solution because the running app can rewrite the global state. The app has enough authoritative local data to reconstruct these associations without mutating conversation content.

I encountered what appears to be the same underlying problem on Windows, but I was able to identify the local-state inconsistency and recover the missing projects/conversation mappings without modifying the actual conversation data.

Environment

• Codex Desktop: 26.803.5235.0
• Package: OpenAI.Codex_26.803.5235.0_x64__2p2nqsd0c76g0
• Subscription: ChatGPT Plus
• OS: Microsoft Windows NT 10.0.26200.0 x64

What happened

After restarting Windows and reopening Codex Desktop, the app behaved like a fresh installation:

• onboarding/preferences appeared again;
• most of my projects disappeared;
• old conversations were no longer visible inside their original projects;
• some existing conversations appeared to become projectless.

At first it looked like the conversations were gone, but the underlying data was still present.

What I found

Before the problem:

• local projects: 8
• project order entries: 8
• projectless threads: 2

After the problem:

• local projects: 1
• project order entries: 1
• projectless threads: 10

However, the conversation data itself was still intact:

• active session JSONL files: 90
• archived session JSONL files: 1
• state_5.sqlite threads: 91
• active: 90
• archived: 1

There was also an index inconsistency:

• session_index.jsonl: 78 lines
• unique usable thread IDs: 77
• active SQLite threads: 90

So about 13 active threads were missing from the session index, even though their session JSONLs and SQLite records still existed.

Important finding

The biggest difference was in:

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

The broken/recreated version was only about 8 KB and contained only one project.

A surviving pre-failure temporary backup file in the same directory was about 123 KB and still contained the original project/workspace metadata, including:

local-projects
project-order
selected-project
active-workspace-roots
electron-saved-workspace-roots
thread-project-assignments
thread-workspace-root-hints
thread-projectless-output-directories
projectless-thread-ids

That older file still contained all 8 original projects.

How I recovered it

First, I fully closed Codex and backed up the entire local Codex directory:

$src = Join-Path $env:USERPROFILE ".codex"
$dst = Join-Path $env:USERPROFILE "Desktop\codex-FULL-backup"

Copy-Item $src $dst -Recurse -Force

Then I listed possible global-state backups:

Get-ChildItem "$env:USERPROFILE\.codex" |
Where-Object {
    $_.Name -like "*codex-global-state*"
} |
Select-Object Name, Length, LastWriteTime

I found a surviving pre-reset state file in the form:

..codex-global-state.json.bak.tmp-<timestamp>-<uuid>

I verified that it was the older, complete state file and then, with Codex fully closed, restored it over the active global-state file:

$root = Join-Path $env:USERPROFILE ".codex"

$old = Join-Path $root "<OLD_GLOBAL_STATE_FILENAME>"
$current = Join-Path $root ".codex-global-state.json"

Copy-Item `
    -LiteralPath $old `
    -Destination $current `
    -Force

I did not modify:

state_5.sqlite
sessions/
archived_sessions/
session_index.jsonl

After reopening Codex:

• all 8 original projects returned;
• old conversations became visible again;
• project associations returned;
• the archived conversation was still present;
• automations and attachments were still intact.

So in my case, the conversations were never deleted. The problem was the local project/history metadata being reset or regenerated inconsistently.

Additional verification

I also compared important user data against the backup:

• active sessions: exact match
• archived sessions: exact match
• automations: exact match
• attachments: exact match
• rules: exact match
• skills: exact match
• auth.json: identical SHA-256 hash

The only notable differences were in runtime/plugin cache files, which appeared to be expected application-update changes rather than user-data loss.

Suggestion

It would be very useful if Codex could automatically detect and repair inconsistencies between:

sessions/*.jsonl
archived_sessions/*.jsonl
state_*.sqlite
session_index.jsonl
.codex-global-state.json

A built-in recovery/reindex option would probably prevent users from thinking their conversations are permanently gone when the actual conversation data is still intact.

#38940 added experimental SQLite-backed project records, thread project_id assignments, project/import, and project/thread change notifications.

This looks like it's possibly groundwork for making project/sidebar state durable, but existing Desktop project assignments and sidebar history don't seem to be fully migrated or rebuilt after an update

It's always pretty disturbing when this happens to me especially since I work on a lot of projects and use a lot of harnesses. Aside from addressing the issue at its root cause so it can never happen, it seems like a Jetbrains style "invalidate caches and restart" kind of button might make sense moving forward?