Windows desktop: corrupted CODEX_HOME global state resets projects/thread assignments; sessions survive but project grouping is lost

Description

Codex Desktop on Windows unexpectedly returned to the "Getting started" / first-run state.

My local repository remained intact and my Codex sessions remained available under Recents, but:

the local Codex project disappeared from the sidebar
project/thread grouping was lost
Codex-specific UI/settings state appeared reset
hundreds of existing chats became ungrouped
re-adding the same folder recreated project entries, but did not restore the old thread/project associations
I accidentally created duplicate project entries for the same folder, and they cannot currently be removed through the UI

ChatGPT and ChatGPT Work were unaffected. The issue appears isolated to Codex local state under CODEX_HOME.

Affected project

C:\Users\<user>\Desktop\<project>

The repository itself still exists and is intact.

Environment

Windows

Current ChatGPT/Codex desktop package:

26.915.4065.0

Incident-time desktop build seen in logs:

26.915.3509.0

Bundled Codex runtime:

codex-cli 0.155.0-alpha.9.2

What happened

At approximately 2026-09-21 10:42 EEST, Codex began failing to load its local global state.

The strongest log evidence is:

2026-09-21T07:42:23.769Z warning [global-state] Failed to load global state errorMessage="Unexpected token '\u0000' ... is not valid JSON" errorName=SyntaxError

This warning repeated several times.

Immediately around this incident, Codex behaved as though it had been reset to first-run state.

Surviving data

The underlying session data was not deleted.

Local inspection found:

hundreds of active session files
several archived session files
the large majority of those sessions still contain the same original project cwd
archived sessions also retain that same cwd

state_5.sqlite still contains:

hundreds of thread records
multiple local project records rooted at the same original project path

The chats are still visible individually in Recents.

Evidence that project/thread assignment metadata was lost

Older valid temporary global-state snapshots from September 3–4 contain:

a local project entry
a project-order entry
hundreds of thread-project assignments
explicit metadata for the original project root

The current reconstructed global state contains:

0 local projects
0 project-order entries
0 thread-project assignments

So the sessions survived, but the project/sidebar/thread-assignment layer was reset or lost after the global-state parse failure.

Additional migration/errors around the incident

2026-09-21T07:43:13.727Z

[host-app-server-projects] Local app-server project migration completed projectCount=2

2026-09-21T07:43:38.251Z

[electron-message-handler] Request failed ... "thread not found: <thread-id>" failureReason=thread_not_found method=thread/settings/update

2026-09-21T08:13:52.617Z

Workspace routing is unavailable

2026-09-21T08:14:55.647Z

[chatgpt-account-lookup] completed authenticatedAccountPresent=true authMethod=chatgpt result=succeeded

2026-09-21T08:23:04.782Z

[host-app-server-projects] Local app-server project migration completed projectCount=4

No explicit account switch, workspace switch, sign-out, or sign-in was found around the incident.

Re-adding the project

OpenAI Support advised me to restore the project sidebar entry using Add new project / Ctrl+O.

I re-added:

C:\Users\<user>\Desktop\<project>

This recreates a project entry, but does NOT restore the historical chats to their previous project grouping.

I also ended up adding the same folder twice, producing duplicate project entries for the same repository.

Those duplicate project entries currently cannot be removed through the normal UI.

Please also investigate whether duplicate local project records or migration state are contributing to this.

Expected behavior

If the global-state file becomes unreadable:

Existing projects/thread assignments should not silently be replaced with an empty state.
A recoverable backup/snapshot should be used where possible.
Sessions that still contain cwd / project information should remain associated with their project.
Re-adding an existing project should ideally recover or reconcile its existing thread associations rather than creating duplicate project identities.
Duplicate project entries pointing to the exact same local path should not be created, or should at minimum be removable.

Actual behavior

After the global-state parse failure:

Codex looked like a fresh install / Getting Started
project sidebar metadata disappeared
thread → project grouping disappeared
sessions remained intact
manually re-adding the folder did not restore the existing associations
duplicate project entries for the same path can now exist
those duplicates cannot currently be removed through the UI

Current status

I am no longer blocked from working.

Creating a new Codex project for the same repository allows me to continue using the repository normally.

The original project/thread grouping is still not restored, and duplicate local project entries remain, but the underlying repository and sessions are intact.

Recovery request

If possible, please advise whether the surviving:

session metadata
state_5.sqlite thread/project records
older .codex-global-state.json.tmp-* snapshots

can be used to safely restore the previous thread/project associations.

I have not manually edited or restored any CODEX_HOME database/state files.

I can provide additional sanitized logs or state metadata if needed.

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

macOS: global-state read EPERM falls back to empty project registry while SQLite projects survive #46919
Linux Desktop loses saved local projects and task-to-project associations while config.toml remains intact #46428

Powered by Codex Action

One additional thing I noticed: some ongoing Codex tasks also disappeared from the UI during this issue. They were not actually gone — when I asked Codex about them, it could still locate them internally and reopen them for me.

I also saw similar task-visibility loss after switching accounts, where some previously visible tasks were no longer shown.

So there may also be a task/session visibility or indexing problem here, not just project/sidebar grouping. The underlying task data can still exist while the UI no longer exposes it.

I can confirm that this issue still occurs on the latest Windows production build.

Environment:

Codex Desktop: 26.917.71314
Build: 10954
Bundled CLI: codex-cli 0.155.0-alpha.16.4
OS: Windows x64
Installed release channel: prod
The problem originally appeared after an unexpected power outage and an application update. Local Codex projects disappeared from the sidebar, while the tasks remained visible as ordinary ungrouped tasks.

Read-only diagnostics after updating to 26.917.71314:

SQLite integrity check: ok
state_5.sqlite contains 9 local project records
project_roots contains the corresponding project roots
project_idempotency_keys contains mappings for all 9 projects
the database currently contains 286 thread records
55 threads have a non-null project_id in SQLite
the Desktop UI and app task listing still return projectId: null for local Codex tasks
local-projects in .codex-global-state.json is empty
thread-project-assignments is absent
the migration state remains:
projectsMigrated: true
threadAssignmentsMigrated: false
one pendingThreadAssignmentId
The startup log reports:

Local app-server project migration completed projectCount=9

However, the 9 local projects are still not returned by the Desktop project list and the local tasks remain under Tasks instead of their projects.

Restarting the application and installing the following updates did not restore the projects:

26.915.4065.0
26.917.51856
26.917.71314
No project folders or conversation files appear to have been deleted. This looks like a project visibility and incomplete thread-assignment migration problem rather than actual conversation data loss.

I have retained complete local backups. I am not attaching the database, global state, transcripts, project names, user paths, or raw logs because they may contain private data and credentials.

Please provide a supported repair or reindex procedure that can rebuild the Desktop project list and thread memberships.

Additional occurrence: local projects disappear after power loss (second incident)

I am affected by a similar problem on Windows. This has now happened twice following a power outage and restart; the latest occurrence was on September 24, 2026. Projects disappear while existing tasks remain visible, and resumed tasks appear to lack recent context.

Environment verified after the incident

Desktop package: OpenAI.Codex 26.915.4065.0.
Running desktop runtime executable: codex-cli 0.155.0-alpha.9.2.
Windows version reported by the diagnostic shell: Microsoft Windows NT 10.0.19045.0.
A separate CLI on PATH reports 0.147.0; that is not the running desktop runtime.

Observed sequence

Use Codex Desktop with saved local projects and ongoing tasks.
An unexpected power outage shuts down the computer.
Restart Windows and open Codex.
Local projects are missing; tasks remain visible but continuity appears incomplete.

This is a report of two real incidents, not a controlled crash reproduction.

Read-only diagnostic findings

list_projects returned ChatGPT projects but no local projects.
list_threads still returned local tasks with their original repository cwd values, but projectId: null.
Both sampled repository directories still exist on disk. Full repository integrity was not assessed.
The current .codex-global-state.json and its .bak both parsed successfully and contained "local-projects": {}.
The global-state migration metadata reported projectsMigrated: true and threadAssignmentsMigrated: false for the local host. This is an observation, not an established cause.
read_thread recovered older messages and command history from two affected tasks. Several recent turns were returned with items: [], including turns marked completed, while older turns contained substantive history.
Session directories and the state/history SQLite files still exist. Their presence does not establish that all history is intact. Database integrity and raw-transcript parity have not yet been checked.

The empty recent turns may be a separate history-loading/projection issue. We have not established transcript deletion, a global-state parse failure at incident time, or the precise root cause. No Codex state/database files were edited during this diagnosis.

Impact and requested investigation

This recurring failure disrupts ongoing work and makes it difficult to know what context survived. Please investigate crash-safe persistence and recovery of local project/thread associations, retention of a last-known-good backup, and recovery of recent history after an unclean shutdown. A supported repair path that preserves sessions and worktrees would be valuable.

This comment intentionally omits personal paths, project names, thread IDs, conversation content, credentials, and raw state files.

On Windows, Codex Desktop lists two distinct local project records for the same repository root, with existing chats associated with both. I have not removed either project or edited internal state. Is there a supported, reversible way to reconcile the records while preserving chat assignments?

Adding a related Windows data point from desktop build 26.924.2738.0. Unlike the original report, ChatGPT Work’s local Projects sidebar was affected in my case after an unexpected power loss. The folders and chats survived, but the local project entries disappeared.

The current .codex-global-state.json and its .bak were parseable, but the local project list and grouping metadata were missing. state_5.sqlite still contained active project records, and an older valid temporary global-state snapshot retained project and thread-assignment metadata.

After backing up the state, we reconciled the old snapshot with the current database rather than restoring the snapshot wholesale. We merged only the relevant project and assignment fields into the JSON state while ChatGPT was fully exited. An edit made while the app was running was overwritten. We did not modify SQLite or re-add the folders. After relaunch, the local projects and their previously grouped chats reappeared.

I did not capture the JSON parse error described in this issue, so I cannot confirm the same root cause. A supported way to recover surviving project metadata would help users in this situation.
From ChatGPT 6-sol

I reproduced the same failure and have additional recovery/migration evidence that may help isolate it.

Windows desktop: local projects disappear after incomplete membership migration; SQLite project data survives and restoring legacy membership fields restores Projects UI
Environment

OS: Windows 11 Pro x64
Desktop app: ChatGPT/Codex desktop app
App version: 26.928.40906
Local state directory: %USERPROFILE%.codex
Projects affected:
- Succinct Website
- latent-recurrence-analyser
- doherty-structural-analyser

The issue persisted across an app update and reinstall.

Summary
Three existing local projects disappeared from the Projects menu and their associated conversations became effectively ungrouped, even though the underlying project records, project-root information, project-ID mappings, and thread working directories remained present locally.

The failure is not project deletion.

The strongest evidence is that, with the app fully closed, restoring only the missing legacy membership structures:

local-projects
thread-project-assignments

from a known-good earlier global-state snapshot makes all three projects immediately reappear in the Projects menu.

No SQLite project rows, thread rows, project roots, or project-ID mappings need to be recreated.

This indicates a project-membership / migration-reconciliation failure rather than loss of the underlying project data.

Observed behavior
After the failure, the live:

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

contained:
local-projects: 0
thread-project-assignments: missing

while migration state remained:

{
"local:C:\Users\Mike\.codex": {
"version": 1,
"projectsMigrated": true,
"threadAssignmentsMigrated": false
}
}

The Projects menu was empty for the affected local projects.

However, the projects themselves still existed in state_5.sqlite.

Surviving SQLite project records
The current project records were still present:

Succinct Website
01a04710-a038-76f2-99bb-816a34d3d30f

latent-recurrence-analyser
01a06187-270e-7d92-98a4-6990121202b9

doherty-structural-analyser
01a0c68f-cb43-7411-9712-8e7c0792055b

Their roots were also retained.

For example:

Succinct Website
C:\Users\Mike.codex.chatgpt-projects\g-p-6a6dcce527c881918a5168f20584533d

latent-recurrence-analyser
C:\Projects\latent-recurrence-analyser

doherty-structural-analyser
C:\Projects\doherty-structural-analyser

Legacy-to-current project mappings also survive
project_idempotency_keys still contains the legacy-ID → current-project-ID relationships:

g-p-6a6dcce527c881918a5168f20584533d
-> 01a04710-a038-76f2-99bb-816a34d3d30f

5cfe92ee-d15d-492b-b71e-9a89af58b41c
-> 01a06187-270e-7d92-98a4-6990121202b9

86714383-fd92-4914-af4b-bd39c357f40b
-> 01a0c68f-cb43-7411-9712-8e7c0792055b

Therefore, the application retains enough information to identify the migrated projects even when the Projects UI is empty.

Thread evidence
Affected thread rows in state_5.sqlite still retain their correct cwd values, but their:

project_id

values remain:

NULL

Examples include threads associated with the Succinct, LRA, and DSA project roots.

This is consistent with the persisted migration state:

projectsMigrated: true
threadAssignmentsMigrated: false

The project migration has completed, while the thread-assignment migration has not.

Recoverable legacy assignment data
A valid earlier global-state snapshot contained three local-projects entries and four thread-project-assignments.
The surviving assignments were:

{
"01a04195-152c-7351-acb7-6578d31f2d50": {
"projectKind": "local",
"projectId": "g-p-6a6dcce527c881918a5168f20584533d"
},
"01a06189-2931-7283-8d6f-3c75d1cb7f98": {
"projectKind": "local",
"projectId": "5cfe92ee-d15d-492b-b71e-9a89af58b41c"
},
"01a06a24-8704-7062-9277-0c1b0b7126f7": {
"projectKind": "local",
"projectId": "5cfe92ee-d15d-492b-b71e-9a89af58b41c"
},
"01a0c68e-2d22-7f60-8613-d2ea69bd2067": {
"projectKind": "local",
"projectId": "86714383-fd92-4914-af4b-bd39c357f40b"
}
}

Minimal recovery test
With the desktop app completely closed:

Before recovery
local-projects: 0
thread-project-assignments: missing
Projects menu: affected projects absent

Manual recovery performed
Only these two structures were restored from a known-good earlier state snapshot:

local-projects
thread-project-assignments

All other current global-state content was preserved.

The migration flags were deliberately left unchanged.

After recovery

local-projects: 3
thread-project-assignments: 4
Projects menu: all three affected projects restored

Migration state remained:

projectsMigrated: true
threadAssignmentsMigrated: false

No SQLite project records were modified.

No project roots were recreated.

No threads were recreated.

No SQLite project-ID mappings were modified.

This demonstrates that the missing Projects/sidebar grouping is recoverable purely by restoring membership metadata.

Why this appears to be a reconciliation problem rather than project deletion
The following all survive the failure:

projects table
project roots
project_idempotency_keys
thread rows
thread cwd values
legacy/current project-ID relationships

What is missing is the project-membership/grouping layer.

Therefore the observed failure can be summarized as:

Project data survives

mappings survive
thread paths survive
project membership disappears
= UI/project-assignment reconciliation failure

What the application appears not to recover automatically
When the application encounters:

projectsMigrated = true
threadAssignmentsMigrated = false

and the legacy membership structures are absent, it does not appear to reconstruct the thread/project associations from the remaining durable state.

In particular, the application does not appear to use the surviving combination of:

projects
project_idempotency_keys
project roots
thread cwd values
existing thread records

to rebuild or complete the missing project membership.

Instead, the affected local projects disappear from the Projects menu even though the underlying records remain intact.

Suspected implementation detail — hypothesis, not confirmed root cause
Inspection of the desktop bundle suggests thread-assignment migration is gated through logic equivalent to:

setThreadAssignmentsEnabled(K().localProjectTaskMembership)

and the built-in default observed for:

localProjectTaskMembership

appears to be false.

The synchronization path appears to perform thread-assignment migration only when thread assignments are enabled and the required project-support / migration-identity conditions are satisfied.

This may help explain why the state remains indefinitely at:

projectsMigrated: true
threadAssignmentsMigrated: false

while affected SQLite thread rows retain:

project_id = NULL

I am presenting this only as a possible implementation explanation. The reproducible/manual-recovery evidence above is independent of this hypothesis.

Expected behavior
If the application starts with:

projectsMigrated = true
threadAssignmentsMigrated = false

and valid migrated projects still exist, the application should do one of the following:

complete the pending thread-assignment migration;
reconstruct thread/project membership from surviving durable metadata;
recover the last valid project-assignment snapshot; or
display an explicit recoverable migration error.

It should not silently show an empty Projects menu while the underlying project records remain valid.

Suggested recovery sources
The application appears to have several possible sources from which membership could be reconstructed:

projects
project_roots
project_idempotency_keys
threads.cwd
existing thread records
previous valid global-state snapshots

A thread whose cwd matches a unique project root, combined with the surviving legacy/current ID mapping, appears sufficient in at least some cases to recover the previous association deterministically.

Suggested regression test
A useful regression test would be:

Create several local projects.
Associate multiple threads with those projects.
Migrate the project records.
Preserve:
- migrated projects rows;
- project roots;
- project_idempotency_keys;
- thread cwd values.
Set/persist:

projectsMigrated = true
threadAssignmentsMigrated = false

Remove or omit:

local-projects
thread-project-assignments

Restart the desktop app.

Expected result:

The application should either reconstruct the memberships or explicitly report a recoverable migration failure.

It should not silently lose the Projects grouping.

Additional global-state durability issue
During the same troubleshooting period, the following files were also observed becoming NUL-filled:

config.toml
.codex-global-state.json
.codex-global-state.json.bak

The affected files retained non-zero file lengths but began with NUL bytes and were no longer parseable as TOML/JSON.

For example, both the primary global-state file and .bak became byte-identical and invalid at the same timestamp.

Older temporary/pre-recovery snapshots remained valid and enabled recovery.

This suggests the persistence path should also be reviewed for crash-safe writes.

An ideal persistence strategy would preserve at least one known-good generation, for example:

write temporary file
flush/fsync
validate new contents
atomically replace live file
only then rotate/preserve previous valid copy

The application should avoid a failure mode in which both:

.codex-global-state.json
.codex-global-state.json.bak

become unusable simultaneously.

Separate Windows stability issue
During troubleshooting, Windows also experienced kernel bugchecks while ChatGPT.exe was the active process.

Two analyzed dumps produced the same:

SYSTEM_SERVICE_EXCEPTION (0x3B)
Exception: 0xC0000005
PROCESS_NAME: ChatGPT.exe
SYMBOL_NAME: nt!MiQueryAddressState+588
FAILURE_BUCKET_ID: AV_nt!MiQueryAddressState
FAILURE_ID_HASH:
{48ac8bd5-3c4d-0c8d-617e-6e5fdec9028e}

However, I do not consider this proven to be caused by the project-migration defect.

The PC became substantially more stable after reducing DDR5 speed from 6400 MT/s to 6000 MT/s, so the kernel crashes may involve separate RAM/IMC stability.

I am including this only so the two symptoms are not accidentally conflated.

Impact
The repositories and conversations are not necessarily lost, but their organization disappears.

This is particularly disruptive because:

Projects appear to have been deleted when they have not.
Historical conversations remain but lose their project grouping.
Re-adding folders manually does not necessarily reconstruct the original thread associations.
The user may create duplicate local project entries while trying to recover.
The data needed for recovery can still exist locally, but the application does not automatically reconcile it.

Requested fix
Please investigate the incomplete project/thread-assignment migration and add automatic reconciliation/recovery when migrated project records survive but legacy project-membership metadata is missing or unreadable.

In particular, please consider:

completing threadAssignmentsMigrated when possible;
reconstructing assignments using surviving project mappings and thread roots;
detecting impossible/partial migration state instead of silently accepting it;
recovering from the last valid global-state generation;
preventing simultaneous loss of both live and backup global-state files.

Related issue
This appears very closely related to:

openai/codex #46987 — Windows desktop: corrupted CODEX_HOME global state resets projects/thread assignments; sessions survive but project grouping is lost. GitHub

My case adds:

confirmed surviving project_idempotency_keys;
exact legacy→current project mappings;
projectsMigrated=true with threadAssignmentsMigrated=false;
affected SQLite threads retaining correct cwd but project_id=NULL;
a successful controlled recovery by restoring only local-projects and thread-project-assignments;
repeated NUL-filled live + backup global-state files.

Additional verified Windows occurrence on October 4, 2026. This matches the global-state parse failure and loss of project grouping described in this issue.

Environment

Desktop app version: 26.930.31730, read from the installed app's package.json.
Microsoft Store package version: OpenAI.Codex 26.930.3930.0.
OS: Windows 11, 10.0.26200, x64.
The user reports the local projects were visible on October 3 and missing on October 4. A recent update is a possible association; the corruption trigger has not been established in a controlled reproduction.

Startup evidence

Selected log messages below use UTC timestamps; the first failure was at 14:07 local time (UTC+08:00):

2026-10-04T06:07:07.593Z warning [global-state] Failed to load global state
  errorMessage="Unexpected token '\u0000', ... is not valid JSON" errorName=SyntaxError
2026-10-04T06:07:07.597Z warning [global-state] Failed to load global state
  errorMessage="Unexpected token '\u0000', ... is not valid JSON" errorName=SyntaxError
2026-10-04T06:07:09.692Z info [host-app-server-projects]
  Local app-server project migration completed projectCount=31
2026-10-04T06:46:27.191Z info [host-app-server-projects]
  Local app-server project migration completed projectCount=31

Findings before recovery

Check	Observed result
Desktop `list_projects`	7 ChatGPT projects; 0 local projects
`state_5.sqlite`: projects / project roots	31 / 31
SQLite `PRAGMA quick_check`	ok
Thread records	479: 473 active, 6 archived
Surviving session record files	479 / 479
Threads with a non-null `project_id`	0 / 479
`.codex-global-state.json` and its `.bak` after startup	Valid JSON, but `local-projects: {}`; saved project order, identity mapping and thread assignments absent
Migration flags	`projectsMigrated: true`, `threadAssignmentsMigrated: false`; 4 pending thread IDs
Older valid temporary global-state snapshot	31 projects, identity mappings matching the surviving SQLite projects, and 65 saved thread assignments

29 of the 31 old project paths exist. Two old paths were unavailable when inspected; the time/cause of that is unknown, and it does not explain disappearance of all project entries.

Recovery status and engineering request

Configuration and SQLite backups were taken. Only the missing desktop project registry, identity mapping, order/pins and 65 saved chat-assignment entries were merged back. The original project tables, root records and session files were not modified by the recovery procedure.

The restored configuration has been validated, but a complete app exit/relaunch and successful sidebar recovery have not yet been verified. The running app still returns zero local projects. This is an attempted workaround, not a confirmed product fix.

The logs confirm a global-state JSON parsing failure involving NUL bytes; they do not establish what originally corrupted the state. Please investigate preservation of last-known-good state and reconciliation of the desktop registry with surviving app-server projects after a load failure, including safe recovery of existing thread assignments.

Private project names/paths, account IDs, conversation contents, credentials, full databases and full raw logs are omitted.

The Oct 4 occurrence above appears to independently confirm the same state transition I reported: NUL-related global-state load failure, surviving app-server project records, projectsMigrated=true / threadAssignmentsMigrated=false, and loss of Desktop membership/grouping.
One useful difference in my case is that the recovery was verified through a complete desktop relaunch: with the app fully exited, restoring only the saved local-projects and thread-project-assignments structures caused all three missing projects and their grouped chats to reappear on restart. SQLite project/thread records and migration flags were not modified.
So the newer occurrence provides direct startup-log evidence of the failure, while my case confirms that the missing UI state can be recovered from the surviving legacy membership metadata. Together these suggest the post-load-failure reconciliation/recovery path is the key area to investigate.

One clarification on recovery durability: in my case, restoring the saved local-projects and thread-project-assignments while the app was fully closed did successfully restore all three project folders on relaunch. However, the desktop app was still unstable afterward and crashed again. Following that crash, the restored project-menu state was lost again because the global-state files were rewritten/corrupted.
I have therefore stopped repeating the manual recovery for now. The recovery procedure is confirmed to work, but it is not a durable solution while the underlying app/state-write instability remains unresolved.
This may be relevant to the recovery design: preserving/reconstructing membership is useful, but the app also needs a crash-safe persistence path so that a subsequent failure cannot immediately destroy the recovered state again.

Additional Windows report: project grouping lost around account switching

This is a related diagnostic report from October 4, 2026, particularly relevant to the earlier account-switching observation in this issue. It concerns partial loss of local chat memberships. The underlying conversations remain accessible.

Environment

Windows desktop package: OpenAI.Codex 26.930.3930.0.
Desktop release recorded in the app log: 26.930.31730.
Active bundled runtime: codex-cli 0.160.0.
OS: Windows 11, 10.0.26200.0, x64.

Observed sequence

The user noticed that existing chats no longer grouped under their local project after switching accounts. Local logs corroborate two logout/login sequences on the same day, around 06:14 UTC and 08:22 UTC.

After each login, requests for account/read and getAuthStatus failed with code -32603 and message "App server account changed". These errors establish that the account transition was observed by the backend; they do not establish that it caused the membership loss.

An older chat was created before the first transition; two affected chats were created between the transitions. All three retain the same repository working directory. Creator identity comparisons, without disclosing identifiers, show that the affected chats were created under a different account/user pair from the older chat.

This is an observed incident, not a controlled reproduction. No additional logout or restart was performed during diagnostics because work was still running.

Read-only findings

Sidebar grouping is set to project.
The two affected chats have no thread-project-assignments entry and are explicitly present in projectless-thread-ids.
The older chat still has its legacy local-project assignment.
All three SQLite thread rows retain their original cwd and have project_id = NULL. The older chat still groups correctly, so NULL alone is not evidence of a new failure.
Two current legacy local-project records have identical names and root paths, but distinct IDs.
A third historical legacy-to-native project mapping survives. Its native idempotency/import entry was created shortly before the first affected chat. That project's record is now absent from both the legacy registry and the native projects table.
The local migration checkpoint reports projectsMigrated: true, threadAssignmentsMigrated: false, with affected chat IDs among the pending assignments. This is a state observation, not proof of a migration defect.
Current global-state JSON parses successfully, and SQLite PRAGMA quick_check returns ok.
No global-state parse failure was found in the inspected incident-day desktop logs. Unlike the original report, we have not established NUL-byte corruption in this occurrence.

Unresolved cause and request

Please investigate whether an account transition, project identity lifecycle, or legacy/native membership reconciliation can leave existing local chats explicitly projectless while equivalent project roots remain available.

The logs do not establish when or why the historical project was removed. Project removal/re-add history is not yet confirmed, and intentional removal is an alternative explanation: the installed desktop bundle has a removal path that moves a project's chats to projectless. We therefore report this as a suspected related regression, without asserting that account switching is the proven root cause.

A supported way to inspect and restore a surviving chat's project membership would also help. No application state/database repair was applied during this investigation.

Personal paths, project names, thread IDs, account IDs, conversation contents, credentials, and raw state/log files are omitted.

Navigation Menu

Repository navigation

Windows desktop: corrupted CODEX_HOME global state resets projects/thread assignments; sessions survive but project grouping is lost #46987

Description

Affected project

Environment

What happened

Surviving data

Evidence that project/thread assignment metadata was lost

Additional migration/errors around the incident

Re-adding the project

Expected behavior

Actual behavior

Current status

Recovery request

Additional occurrence: local projects disappear after power loss (second incident)

Environment verified after the incident

Observed sequence

Read-only diagnostic findings

Impact and requested investigation

Environment

Startup evidence

Findings before recovery

Recovery status and engineering request

Additional Windows report: project grouping lost around account switching

Environment

Observed sequence

Read-only findings

Unresolved cause and request

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Windows desktop: corrupted CODEX_HOME global state resets projects/thread assignments; sessions survive but project grouping is lost #46987

Description

Description

Affected project

Environment

What happened

Surviving data

Evidence that project/thread assignment metadata was lost

Additional migration/errors around the incident

Re-adding the project

Expected behavior

Actual behavior

Current status

Recovery request

Activity

github-actions commented on Sep 21, 2026

rudinsaunins131 commented on Sep 23, 2026

wamamediagroup commented on Sep 24, 2026

Hatt3rPi commented on Sep 24, 2026

Additional occurrence: local projects disappear after power loss (second incident)

Environment verified after the incident

Observed sequence

Read-only diagnostic findings

Impact and requested investigation

mcea93 commented on Sep 26, 2026

top-ace commented on Sep 28, 2026

mmckimm commented on Oct 2, 2026

weia8961-bot commented on Oct 4, 2026

Environment

Startup evidence

Findings before recovery

Recovery status and engineering request

mmckimm commented on Oct 4, 2026

turtlenosleep commented on Oct 4, 2026

Additional Windows report: project grouping lost around account switching

Environment

Observed sequence

Read-only findings

Unresolved cause and request

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions