Windows Codex Desktop selectively loses historical local sessions while older legacy threads survive, alongside incomplete project-assignment migration

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

26.825.6671

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 Home 25H2, build 26200.9168, AMD64 (64-bit)

What issue are you seeing?

Codex Desktop on Windows shows two distinct local-history failures:

Incomplete project-assignment migration. Existing threads survived on disk but lost their Project association. The persisted migration state was projectsMigrated = true while threadAssignmentsMigrated = false. Before a backed-up repair, 0 of 11 uniquely attributable Project-to-thread assignments were present in threads.project_id; the legacy JSON assignment map held 9 of 11, while sidebar ordering retained all 11.
Selective session/rollout loss. I remember additional primary conversations in the “3D打印产品报价系统” Project from approximately one to two months earlier. Those conversations are absent from every local store and VSS snapshot examined, although still older May 2026 legacy threads remain intact and usable.

The user-visible symptom was that Projects still existed, but some historical conversations disappeared. Some surviving conversations could be reassociated with their Projects, but the remembered missing primary conversations cannot currently be recovered because their thread rows and rollout files are absent from every available local dataset and snapshot.

This is not a claim that all history disappeared, and I cannot identify a specific Codex, ChatGPT, or Windows update as the cause.

What steps can reproduce the bug?

I do not currently have a deterministic reproduction because the loss appears to have occurred during an earlier in-place app/project migration.

Observed sequence:

Use Codex Desktop on Windows over multiple months with several local Projects and local conversation history.
Update Windows, Codex Desktop, and ChatGPT Desktop in place over time. I did not uninstall/reinstall Codex or ChatGPT and did not reinstall Windows.
After later app/project migrations, some Projects still exist but part of their historical conversation list is missing.
Inspecting local Codex state showed projectsMigrated=true while threadAssignmentsMigrated=false.
Surviving threads could be reassigned because their SQLite rows and rollout files still existed.
Other remembered primary conversations could not be found in:
- state_5.sqlite
- sessions/rollout-*.jsonl
- session_index.jsonl
- thread_history_1.sqlite
- the pre-repair backup
- two Windows VSS snapshots

Important control case:
A May 21, 2026 legacy primary thread still exists and works normally in the UI, even though it is older than the missing conversations. Its rollout is intact and hash-identical across live data and VSS snapshots.

Stable pre-investigation baseline:

4 Projects
44 threads
44 rollout/session files
18 primary user threads
26 child/helper threads

Two additional guardian/review threads were generated only during the forensic investigation and are not recovered history.

What is the expected behavior?

App updates and Project migrations should preserve all existing primary local sessions and rollout files.
Migrated Projects should retain their thread assignments, or provide a supported reconciliation/recovery path.
Threads that cannot be assigned to a Project should remain available as Projectless rather than disappearing.
Older local conversations should not selectively disappear while even older legacy conversations remain intact.

Additional information

Key forensic findings:

A May 21, 2026 legacy Project thread remains fully usable.
Its rollout is 37,462,645 bytes / 756 records and is hash-identical in live data, VSS7, and VSS8.
It is absent from both session_index.jsonl and thread_history_1.sqlite, showing those indexes are not required for historical survival.
A July 28 quotation-system thread also survives and underwent the same legacy Project ID -> app-server Project ID remapping.
Project-assignment migration was incomplete, but this only explains surviving threads losing Project membership; it cannot explain remembered sessions whose SQLite rows and rollout files are entirely absent.
VSS snapshots from Aug 30 and Aug 31 contained no additional thread/session IDs outside the live set.
logs_2.sqlite contained additional internal thread IDs, but forensic classification identified no missing primary-user conversation among them.

Related but not identical: #26157, #41867, and #41864.

#26157 appears to cover the project/sidebar mapping failure where the underlying local sessions still exist. My case additionally includes remembered primary conversations for which neither the thread rows nor rollout/session files are present in the live store or available VSS snapshots.

02_TECHNICAL_TIMELINE.md
03_DATASET_SUMMARY.md
05_PROJECT_MIGRATION_SUMMARY.md
06_VSS_FORENSICS.md
07_PRIVACY_REDACTION_REPORT.md

I have a redacted diagnostic package containing a technical timeline, dataset comparison, Project-migration analysis, and VSS forensic results. Raw SQLite databases, rollout files, prompts, source code, credentials, and account identifiers are not included.

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

Windows Desktop data loss: 457 local rollout JSONL transcripts deleted while thread records remain #41048
Windows 26.826.11250 chats disappear after restart; feedback upload fails #41057
Windows Desktop: conversations disappear from UI even though JSONL sessions still exist; add first-party recovery/reindex tool #40779

Powered by Codex Action

Also happening on macOS

I dug into the current public Project source because this report usefully keeps assignment loss separate from the physically missing-session branch. One concrete retry edge may matter for the first half:

PR Add experimental app-server project APIs #38940's project/import assigns supplied existing threads when the Project is first created.
StateRuntime::create_project checks project_idempotency_keys before validating or applying thread_ids. A same-key replay returns the existing Project with created=false.
The app-server emits thread/project/updated for an import only when created is true. Its project_import_is_atomic_and_notifies_after_commit_in_order test explicitly expects a same-key replay to produce no Project or thread-assignment notifications.

So if Desktop has already persisted canonical Project creation but its legacy thread-assignment phase is incomplete, replaying the same project/import is not an assignment reconciliation mechanism. The existing thread metadata assignment path can reconcile surviving threads independently.

A focused migration regression could seed a Project under its migration idempotency key, leave known surviving legacy threads with project_id = NULL, restart with Project creation already complete / assignment migration incomplete, reconcile and verify those assignments, and only then mark the assignment phase complete. Missing legacy thread IDs should remain explicit unresolved/projectless cases rather than becoming grounds to hide or delete surviving conversations.

This is a source-grounded survivable partial-state path, not a claim that it caused the state reported here. It also does not explain the separate conversations whose rows and rollout files are physically absent.

Additional Windows 10 data point that may help isolate this to Codex Desktop rather than the underlying sessions/account.

Environment:

Codex Desktop 26.825.6671
Windows 10 22H2 / build 19045, x64
ChatGPT Plus
Separate ChatGPT Classic and Codex Desktop apps installed

Key control case: the Codex VS Code extension on the same machine/account can still see the latest Codex session correctly and can access/resume the expected local history. Codex Desktop cannot. This seems useful because it suggests the underlying sessions/account are intact and the remaining failure is Desktop-specific project/sidebar/reconciliation behavior.

Forensics before recovery:

state_5.sqlite: 9 rows in projects, 9 matching project_roots
threads: 139 rows total
all 139 initially had project_id = NULL
global state had projectsMigrated = true while host-specific threadAssignmentsMigrated = false
session rollout files and CWDs were still present

After reconstructing only unambiguous surviving assignments from CWD -> existing project_roots:

113/139 threads have valid existing project_id values
Desktop now recognizes project membership on individual threads (for example the project name appears when inspecting/hovering a thread)
but the Projects sidebar still renders No projects
the expected latest session is also absent from Desktop Recent, even though it is present in SQLite/session files and visible in the VS Code extension
Desktop search appears to surface ChatGPT Classic conversations rather than the missing local Codex sessions, so it is not a practical recovery path
creating a new Codex Desktop chat cannot select an existing project because the project picker/sidebar is empty

There is also a second Desktop catalog at .codex/sqlite/codex-dev.db:

local_thread_catalog: 488 rows total
local host: 107 distinct rows, initially 107/107 with project_id = NULL
ChatGPT host: 381 rows, 343 with project IDs
manually copying existing app-server project UUIDs into the unambiguous local catalog rows was not durable: after Desktop restart/reconciliation, only 2 local catalog rows retained a project ID
this makes local_thread_catalog look derived/reconciled rather than authoritative

Most useful differentiator: VS Code Codex extension works with the same account/local data while Codex Desktop 26.825.6671 shows an empty Projects section and omits the latest local session.

This may be worth testing as a migration/restart regression where canonical projects/project_roots survive, thread assignment migration is incomplete, and Desktop's local catalog/sidebar reconciliation fails to repopulate even after canonical threads.project_id is valid. The VS Code extension behavior provides a useful control that the local session itself is still recoverable.

Follow-up from the same Windows 10 / ChatGPT Plus machine after deeper read-only inspection of the installed Codex Desktop renderer/main-process code and current runtime state.

The empty Projects sidebar is now isolated to a second Desktop-specific failure above the migration/database layer.

Environment now:

Codex Desktop 26.831.2377
Windows 10 22H2 / build 19045, x64
Personal ChatGPT Plus account
Same account still works in the Codex VS Code extension

Important correction to my earlier hypothesis: Desktop does not think this account is Free. The current auth/account-info path resolves chatgpt_plan_type as plus, and the renderer receives plan = "plus" correctly.

Installed-code/runtime tracing shows the Projects page ultimately derives showLocalProjects from a policy path that can switch between ordinary local access and workLocal via feature gate 1463309241.

Observed/effective path on the affected Desktop session:

plan = "plus"
  -> feature gate 1463309241 routes policy to workLocal
  -> workLocal evaluates workspace setting adminWorkLocalEnabled
  -> personal Plus account has no enabled workspace-admin value for this setting
  -> policy result: denied / workspace-disabled
  -> showLocalProjects = false
  -> Projects page receives/has local project groups but renders []
  -> sidebar shows "No projects"

This is distinct from the earlier migration damage. The local data has been independently verified as still present:

canonical state_5.sqlite contains 9 projects + roots
historical sessions/rollouts still exist, including the previously missing recent thread
after restoring the intended legacy<->app-server project-ID mapping, Desktop still shows No projects
read-only inspection indicates the project data reaches the renderer; the visibility gate is what removes it from the UI

The legacy/app-server project mapping mechanism is also explicit in the installed app code (app-server-project-id-by-legacy-project-id-by-host), so the earlier missing mapping was a real migration defect, but fixing that mapping alone does not restore the sidebar because the entitlement/feature-gate path still sets showLocalProjects=false.

Why the VS Code control case matters even more now:

same machine
same ChatGPT Plus account
same local session/project data
VS Code Codex extension can access the sessions/project context
Desktop alone applies this workLocal/workspace-admin gating path to the Projects UI

This suggests there are two independent regressions in this case:

incomplete project/thread migration / missing legacy-to-app-server mapping;
Desktop Projects UI routed through a workLocal workspace-admin entitlement for a personal Plus account, hiding otherwise valid local projects.

No auth tokens, account IDs, private prompts, project source, or raw databases are included here. No entitlement bypass or app patch was applied.

A useful regression test would be: personal ChatGPT Plus account + local projects + gate 1463309241 enabled, then verify that Projects visibility does not depend on an Enterprise/managed-workspace adminWorkLocalEnabled value. The VS Code extension behavior is a useful comparison because it does not exhibit the same failure on this account.

I can independently reproduce the same failure pattern on Windows with a personal ChatGPT Plus account, and I was able to isolate it above the canonical project/database layer.

Environment

Windows 11, build 26200
Codex Desktop build observed in the bundled runtime: 26.901.20858
Bundled app-server / CLI: 0.153.0-alpha.5
Personal ChatGPT Plus account
Custom CODEX_HOME on a secondary drive

User-visible symptom

The Desktop sidebar renders:

Projects
No projects

while Recent threads are still visible.

Canonical data is intact

After repairing the incomplete thread assignment migration, read-only diagnostics show:

.codex-global-state.json
  local-projects                 = 8
  thread-project-assignments     = 110
  project-order                  = 8
  projectless-thread-ids         = 2

migration state
  projectsMigrated               = true
  threadAssignmentsMigrated      = false

state_5.sqlite
  integrity                      = ok
  projects                       = 8
  project_roots                  = 9
  threads                        = 138
  threads with project_id        = 110
  unarchived                     = 86

So the project definitions, roots, and most thread assignments are present and internally consistent.

Decisive app-server control

I then queried the bundled Codex app-server directly using the official project/list API.

With both CODEX_HOME and CODEX_SQLITE_HOME explicitly pointed at the active Codex home:

initialize.codexHome = <custom Codex home>
project/list count   = 8

All 8 projects and their roots are returned correctly.

I repeated the same probe using the normal inherited environment (CODEX_HOME set, no explicit CODEX_SQLITE_HOME override):

initialize.codexHome = <custom Codex home>
project/list count   = 8

Again, all 8 projects are returned.

This rules out, for this reproduction:

missing/corrupt projects rows;
missing project_roots;
wrong SQLite home selection;
failure of the app-server project/list path;
loss of the underlying local project data.

The effective pipeline is therefore:

state_5.sqlite          -> 8 projects        OK
.codex-global-state     -> 8 projects        OK
app-server project/list -> 8 projects        OK
Desktop sidebar         -> "No projects"    FAIL

Desktop catalog is also populated

The Desktop catalog is not empty either:

sqlite/codex-dev.db
  local_thread_catalog rows              = 43
  local_thread_catalog_metadata rows     = 1
  local_thread_catalog_sync_state rows   = 1
  initial_build_complete                 = 1

So this is not the earlier initial_build_complete=0 catalog failure mode.

Why this seems useful for this issue

This reproduction is very close to the later Windows report in this thread where canonical project data and threads.project_id were repaired successfully but Desktop still rendered No projects.

I have not patched the Desktop bundle or bypassed any policy/feature gate, so I cannot independently claim that feature gate 1463309241 / workLocal / adminWorkLocalEnabled is the cause on my build. However, the direct project/list control above strongly isolates my remaining failure to the Desktop layer after the app-server has already returned the full valid project set.

It may be useful to add a regression test for:

personal Plus account
+ valid local projects in state_5.sqlite
+ valid thread project assignments
+ project/list returns non-empty data
=> Desktop must render the same local projects

The important point from my reproduction is that project recovery at the SQLite/global-state level is not sufficient: the backend can be fully healthy and return all projects while the Windows Desktop UI still displays an empty Projects section.

I can provide additional sanitized output if maintainers want a specific field or app-server request/response shape. No raw DBs, project names, paths, prompts, or credentials are included here.

Additional diagnostic linkage for my Windows 10 / ChatGPT Plus reproduction:

Codex in-app Feedback ID: no-active-thread-01a07104-4016-78b1-a83a-8f91506cf2d9

I submitted this through the Codex Desktop feedback function after reproducing the same Projects -> No projects state described in my comments above.

The feedback corresponds to the affected Desktop state where:

local/canonical project data still exists;
the same sessions remain accessible via the Codex VS Code extension;
Desktop renders an empty Projects section;
read-only runtime/code analysis isolated the remaining failure to the Desktop visibility/entitlement layer after project data is available.

This Feedback ID should allow the Codex team to correlate the public GitHub report with the private diagnostic/performance trace collected by the app.

I can confirm the same incomplete project-assignment migration on the current Codex Desktop app.

Codex app version: 26.901.51231

User-visible symptoms:

Existing local Projects disappeared from the Projects sidebar/project picker.
The conversations themselves still exist, but are now shown under Recents instead of their previous Projects.
Newly created Projects work normally.

I performed a read-only comparison of the current Codex state with a local state backup from before the regression.

The older state still contains:

local-projects
thread-project-assignments
electron-saved-workspace-roots
the previous local Project definitions and thread-to-Project assignments

In the current state, the same surviving threads have thread-workspace-state-v1 entries and their workspace/CWD information is still present, but their project value is null.

Most importantly, both the older backup and current state report:

projectsMigrated = true
threadAssignmentsMigrated = false

This appears consistent with a partial migration where workspace/thread data survives, but the historical thread-to-Project assignments are not reconciled into the new Project model.

I have intentionally omitted all Project names, repository names, local paths, thread IDs, Project IDs, account identifiers, source code, prompts, and raw Codex state/database files for privacy.

I can provide additional redacted structural information if useful for debugging.

Adding a macOS reproduction of the same incomplete project-assignment migration class.

Environment

ChatGPT Desktop / Codex 26.908.40834
macOS 26.6.2, Apple Silicon

Reproduction and readback

Local Codex tasks were created against an existing saved Git project.
The affected tasks remain readable when addressed by their exact task IDs.
The same tasks are absent from list_threads / the project sidebar.
A single supported pin + readback attempt did not make them visible.
A full app restart did not change the result.

Redacted migration state after restart

projectsMigrated=true
threadAssignmentsMigrated=false
pendingThreadAssignmentIds: 8
all 8 pending task IDs are readable
6 are list-visible; the same 2 remain readable-but-invisible

Expected

Readable tasks assigned to the saved project should appear in list_threads and the project sidebar after migration/restart.

Safety / data integrity

No task IDs, project paths, chat contents, or logs are included here.
No manual edits were made to .codex-global-state.json, SQLite, or internal indexes.
No replacement tasks were launched, so this reproduction did not create duplicate tasks or worktrees.

This looks like a desktop projection/assignment migration defect rather than missing task data, because exact-ID reads continue to work while list/sidebar projection and the migration completion flag remain stale. Is there a supported way to retry or repair the assignment backfill on macOS?

Navigation Menu

Repository navigation

Windows Codex Desktop selectively loses historical local sessions while older legacy threads survive, alongside incomplete project-assignment migration #41874

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

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

Environment

User-visible symptom

Canonical data is intact

Decisive app-server control

Desktop catalog is also populated

Why this seems useful for this issue

Environment

Reproduction and readback

Redacted migration state after restart

Expected

Safety / data integrity

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows Codex Desktop selectively loses historical local sessions while older legacy threads survive, alongside incomplete project-assignment migration #41874

Description

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

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 Aug 31, 2026

mattLummus commented on Aug 31, 2026

84dnnvbdvp-debug commented on Aug 31, 2026

agerritzen commented on Sep 1, 2026

agerritzen commented on Sep 2, 2026

FawziLinggo commented on Sep 3, 2026

Environment

User-visible symptom

Canonical data is intact

Decisive app-server control

Desktop catalog is also populated

Why this seems useful for this issue

agerritzen commented on Sep 5, 2026

3nines commented on Sep 7, 2026

calltosveta-afk commented on Sep 13, 2026

Environment

Reproduction and readback

Redacted migration state after restart

Expected

Safety / data integrity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions