Windows Codex app and VS Code extension hang after migration with legacy .codex; renaming .codex restores both clients

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

26.715.4045.0

What subscription do you have?

IU ChatGPT Edu

What platform is your computer?

Microsoft Windows NT 10.0.26100.0 x64

What issue are you seeing?

After a recent Windows app update, both the ChatGPT/Codex desktop app and the native Windows Codex VS Code extension became unusable.

Both clients stopped at the OpenAI/Codex logo during startup and never reached the sign-in or main UI. No error message was displayed.

Closing the desktop window did not terminate the background processes; I had to end the ChatGPT/Codex process group in Task Manager.

I tried all of the following without resolving the problem:

1. Ended all ChatGPT/Codex processes.
2. Restarted the app.
3. Restarted Windows.
4. Used Windows App Settings → Repair.
5. Used Windows App Settings → Reset.
6. Checked Microsoft Store for updates.
7. Uninstalled the app, restarted Windows, and reinstalled it.
8. Opened the native Windows Codex VS Code extension.

After reinstalling, the desktop app still froze at the logo. The native Windows VS Code extension also froze at the same logo screen.

My WSL Codex extension continued working normally. Windows and WSL use separate .codex directories; I do not share CODEX_HOME between them.

Renaming the existing Windows state directory %USERPROFILE%\.codex to %USERPROFILE%\.codex.disabled immediately fixed both clients. The native Windows VS Code extension recreated a fresh .codex, completed Windows setup, and worked normally. The ChatGPT/Codex desktop app also started normally and showed the new onboarding UI.

This strongly suggests that legacy state under %USERPROFILE%\.codex was incompatible with the updated clients or was not migrated correctly.

What steps can reproduce the bug?

I cannot reproduce the original corruption from a fresh state, but I can reliably reproduce the startup failure using the preserved legacy .codex directory.

1. Close the ChatGPT desktop app, native Windows VS Code, and all Windows codex.exe processes.
2. Replace the current %USERPROFILE%\.codex directory with the preserved legacy .codex directory from before the recent app update.
3. Start the ChatGPT/Codex Windows app.
4. Observe that it remains indefinitely on the OpenAI/Codex logo and never reaches the UI.
5. Close the window.
6. Observe that the background ChatGPT/Codex processes remain running.
7. Start native Windows VS Code and open the Codex extension.
8. Observe that the extension also remains stuck on the Codex logo.
9. Close both clients and rename the legacy .codex directory.
10. Start either client again.
11. Observe that a fresh .codex is created and both clients start normally.

No prompt is submitted because the failure occurs before the UI becomes usable.
Token limit usage and context window usage are therefore not applicable.

One legacy local session ID present in the old state was: 019db3b7-dec4-78c0-ba24-b6eff55e0471
Its metadata identified it as:

• Originator: codex_vscode
• Codex version: 0.122.0-alpha.13
• Original workspace: C:\Users\<redacted>\OneDrive - <institution>\Documents\<redacted-project-path>

The original workspace directory no longer exists.

What is the expected behavior?

The updated Windows desktop app and native Windows VS Code extension should either:

migrate compatible legacy .codex state successfully; or
detect incompatible/corrupt state and display a clear recovery message with an option to rebuild local state safely.

They should not hang indefinitely at the startup logo with no error message.

Closing the desktop window should also terminate the associated process tree normally.

Existing local Codex session history should either remain visible after migration or be explicitly reported as unsupported or requiring migration. It should not silently disappear.

Additional information

This issue affected both Windows clients because they shared the same %USERPROFILE%\.codex directory.

The WSL Codex extension was unaffected because it uses a separate Linux ~/.codex.

Repair, Reset, reboot, uninstall, and reinstall did not help because the legacy %USERPROFILE%\.codex directory remained in place.

The old .codex directory contained local session files and state databases. After rebuilding fresh state, I copied one old rollout file into the new sessions directory and verified that its thread row existed in the active SQLite database. I also updated threads.thread_source to user; the update succeeded, but the old chat still did not appear in either client.

This suggests a secondary migration/history compatibility problem affecting older codex_vscode sessions.

I retained the original .codex.disabled directory and can provide redacted file listings, schema details, session metadata, or logs if needed. I will not attach the full directory publicly because it may contain local paths, prompts, command output, and authentication-related state.

Note:
GitHub suggested #33909 as a potential duplicate. Its desktop-app symptom and
.codex workaround are very similar, but my case also affects the native Windows
VS Code Codex extension through the same shared .codex state. The suggested
issues #33780 and #33873 appear to involve different or less-specific causes.

Possibly related:

• #33909 — closest match: old .codex causes startup hang; fresh .codex works
• #33873 — post-update Windows app unresponsiveness
• #33780 — visually similar hang, but diagnosed as HID enumeration deadlock
• #23841 — .codex/state migration issue, but involves shared Windows/WSL state