[Windows] Confirming workspace reference addition while moving a Work thread permanently bricks Desktop

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

26.721.31836

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

On Windows, moving an existing local Work conversation from one local
Codex project to another immediately corrupted the Desktop application's
persistent local state and made the entire application unusable.

The application could not be recovered by restarting it or by
uninstalling and reinstalling it. It only recovered after I manually
quarantined the Codex global-state files under %USERPROFILE%\.codex.

Environment

Source local project:

D:\Resources\workspace\gptLM

Target local project:

D:\Resources\workspace\learning-companion

The moved Work conversation had a Chinese title.

Both project filesystem paths contain only ASCII characters, so this
reproduction does not require a Unicode filesystem path.

Steps that triggered the issue

1. I had an existing local Work conversation under:

D:\Resources\workspace\gptLM

1. I dragged that Work conversation into the local project:

D:\Resources\workspace\learning-companion

1. Codex displayed a confirmation dialog.

I no longer have the exact original wording of the dialog, but it
stated that continuing would also add the source workspace reference:

D:\Resources\workspace\gptLM

to the target project.

1. I confirmed the operation.

1. Immediately after confirmation, the entire ChatGPT/Codex Desktop

application entered its fatal error page.

Full visible error text

糟糕，出错了

更新 ChatGPT

重试
<img width="1277" height="813" alt="Image" src="https://github.com/user-attachments/assets/fec24584-7fea-481e-9921-155cd1c601f3" />

1. Closing and reopening the application did not help. Every launch

returned to the same fatal error page.

1. Clicking Retry did not recover the application.

1. Uninstalling and reinstalling the Desktop application also did not

fix the problem. The broken state survived reinstall.

Recovery procedure

I first backed up the complete directory:

%USERPROFILE%\.codex

I then fully terminated the ChatGPT and Codex processes and renamed or
quarantined these files:

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

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

I did not modify the sessions directory or state_5.sqlite.

After restarting the application, it opened normally again.

Result after recovery

• The local Work conversation records were still present.
• Their corresponding filesystem working directories were still valid.
• The conversation contents did not appear to be lost.
• All previously configured local project/workspace groupings disappeared.
• Existing local Work conversations were redistributed into Recents.
• Reinstalling alone had not fixed the issue, but removing the persisted

global-state files did.

Actual behavior

A supported drag-and-drop operation, followed by confirming the displayed
workspace-reference prompt, wrote a persistent state that caused the
entire Desktop application to crash on every startup.

The failure blocked access not only to the moved conversation, but also
to all unrelated projects and conversations in the application.

Expected behavior

Moving a local Work conversation between projects should update the
conversation assignment and workspace references atomically.

If any part of the operation fails, the move should roll back safely.

An invalid or inconsistent project assignment should not crash the
entire application.

At startup, Codex should detect and quarantine an invalid global-state
record instead of loading the same fatal state indefinitely.

Uninstalling and reinstalling the application should either clear the
invalid UI state or provide a supported recovery path.

Additional diagnostic information

The fact that quarantining .codex-global-state.json restored the
application, while leaving the session files and SQLite database intact,
suggests that the failure was in persisted Desktop project/workspace/UI
state rather than in the project files themselves.

This is an inference based on the recovery behavior; I have not yet
identified the exact corrupted property.

I preserved the following evidence:

• A complete backup of %USERPROFILE%\.codex from immediately after the

failure

• The original quarantined .codex-global-state.json
• The original .codex-global-state.json.bak
• The newly regenerated healthy global-state file
• The affected session records
• Desktop application logs
• A screenshot of the persistent fatal error page

I have not attempted to reproduce the issue again because the first
occurrence made the entire Desktop application unusable and required
manual filesystem intervention to recover.

What steps can reproduce the bug?

Reproduction steps

This is a Desktop UI/state persistence bug, so there is no code snippet that reproduces it.

Environment

• Platform: Windows x64
• Source local Codex project:

D:\Resources\workspace\gptLM

• Target local Codex project:

D:\Resources\workspace\learning-companion

• The moved Work conversation had a Chinese title.
• Both filesystem paths contain only ASCII characters.

Steps

1. Create or open two existing local Codex projects:

• D:\Resources\workspace\gptLM
• D:\Resources\workspace\learning-companion

1. Open an existing local Work conversation currently grouped under the

gptLM project.

1. Drag that Work conversation from the gptLM project into the

learning-companion project in the Desktop sidebar.

1. Codex displays a confirmation dialog.

I no longer have the exact wording, but the dialog explained that the
workspace reference for:

D:\Resources\workspace\gptLM

would also be added to the target project.

1. Confirm the operation.

1. Immediately after confirmation, the entire ChatGPT/Codex Desktop

application enters the fatal error page:

糟糕，出错了
更新 ChatGPT
重试

1. Fully close and reopen the application.

1. The application opens directly into the same fatal error state and

remains unusable.

1. Uninstall and reinstall the Microsoft Store/Desktop application.

1. Launch the reinstalled application.

1. The same fatal error still occurs because the corrupted state under

%USERPROFILE%\.codex survives the reinstall.

Recovery required

The application only recovered after I:

1. Fully terminated all ChatGPT and Codex processes.
2. Backed up the complete %USERPROFILE%\.codex directory.
3. Renamed/quarantined:

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

1. Restarted the application.

After doing this, the application opened normally again.

Session and context information

• Session ID: unavailable. The application became unusable immediately,

and I did not retrieve the affected thread ID before recovery.

• Token-limit usage: not applicable.
• Context-window usage: not applicable.
• No code execution or model response triggered the bug; it was caused

by a local Desktop drag-and-drop/project-assignment operation.

What is the expected behavior?

Moving a local Work conversation between local Codex projects should be
a safe and atomic operation.

After confirming the move:

1. The Work conversation should appear under the target project.
2. The source workspace reference should be added to the target project

only if required and only if the operation completes successfully.

1. All related metadata, including the thread-to-project assignment,

workspace references, working directory, and persisted Desktop state,
should remain consistent.

1. If any part of the operation fails, Codex should roll back the move

and preserve the previous valid state.

1. A malformed or inconsistent project assignment should not crash the

entire Desktop application.

1. Startup should detect, skip, repair, or quarantine an invalid state

entry instead of reopening the same fatal error indefinitely.

1. Restarting or reinstalling the application should provide a supported

recovery path without requiring manual modification of files under
%USERPROFILE%\.codex.

1. Existing unrelated projects and Work conversations should remain

accessible even if one conversation cannot be moved or rendered.

Additional information

Severity and impact

This was an application-blocking failure.

A normal, confirmed sidebar operation made the entire Desktop application
unusable, including unrelated local projects and Work conversations.

Restarting the application and uninstalling/reinstalling it did not fix
the problem. Manual filesystem intervention was required.

State after recovery

After quarantining .codex-global-state.json:

• The application opened normally.
• Existing local Work conversation records were still present.
• Their corresponding filesystem working directories were still valid.
• No conversation content appeared to be lost.
• All previously configured local project/workspace groupings disappeared.
• Existing Work conversations were redistributed into Recents.
• The sessions directory and state_5.sqlite were not modified during

recovery.

This indicates that the Work/session data itself remained available, but
the persisted Desktop project/workspace/UI state had become invalid or
inconsistent.

Important path detail

The two involved project paths were:

• D:\Resources\workspace\gptLM
• D:\Resources\workspace\learning-companion

Both paths contain only ASCII characters.

The moved conversation had a Chinese title, but I have not confirmed
whether the title contributed to the failure.

Therefore, this reproduction does not require a Unicode filesystem path.

Diagnostic inference

Because removing only .codex-global-state.json restored the application
while leaving the session files and SQLite state untouched, the failure
appears to be associated with persisted Desktop project/workspace state.

The confirmation dialog suggests that the operation attempted to update
both:

• the Work conversation's project assignment; and
• the source workspace reference attached to the target project.

It is possible that these updates were only partially completed or
produced an invalid reference relationship. This is an inference based
on the observed behavior; I have not yet identified the exact corrupted
property.

Evidence preserved

I still have:

• a complete backup of %USERPROFILE%\.codex from immediately after the

failure;

• the original quarantined .codex-global-state.json;
• the original .codex-global-state.json.bak;
• the newly generated healthy global-state file;
• the affected session data;
• Desktop application logs;
• a screenshot of the persistent fatal error page.

These files may contain private conversation titles, paths, prompts, and
other personal data, so I have not attached the complete raw files
publicly. I can provide redacted diffs or specific diagnostic sections
if requested.

I have not attempted to reproduce the issue again because the first
occurrence completely blocked the application and required manual state
recovery.