[Windows] Moving a thread between/out of projects can persist a half-applied workspace migration and break Codex Desktop startup

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

26.721.3996.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Moving an existing local Codex thread between projects / out of a project can leave the workspace migration in a partially-applied persistent state.

After this occurred, the entire Codex Desktop UI became unusable and showed only:

Something went wrong

with "Update ChatGPT" and "Retry" buttons.

Restarting Codex, restarting Windows, and uninstalling/reinstalling the Microsoft Store app did not fix the issue. Renaming ~/.codex and allowing Codex to generate fresh local state made the app start normally again, which isolated the problem to persisted local Codex state.

I backed up the original ~/.codex directory and was able to further isolate the failure to project/thread workspace state in .codex-global-state.json.

The affected thread was originally running in Project A. After the failed project move, its persisted state contained a half-applied migration:

{
  "thread-project-assignments": {
    "<THREAD_ID>": {
      "projectKind": "local",
      "projectId": "<PROJECT_B_ID>",
      "path": "C:\\Users\\<USER>\\Documents\\ProjectB",
      "cwd": "C:\\Users\\<USER>\\Documents\\ProjectB",
      "pendingCoreUpdate": true
    }
  }
}

At the same time, the per-thread workspace state still had Project A as the applied state, while Project B was pending:

{
  "project": {
    "projectKind": "local",
    "projectId": "<PROJECT_B_ID>",
    "path": "C:\\Users\\<USER>\\Documents\\ProjectB"
  },
  "applied": {
    "projectSources": [
      "C:\\Users\\<USER>\\Documents\\ProjectA"
    ],
    "cwd": "C:\\Users\\<USER>\\Documents\\ProjectA",
    "runtimeWorkspaceRoots": [
      "C:\\Users\\<USER>\\Documents\\ProjectA"
    ]
  },
  "pending": {
    "projectSources": [
      "C:\\Users\\<USER>\\Documents\\ProjectB",
      "C:\\Users\\<USER>\\Documents\\ProjectA"
    ],
    "cwd": "C:\\Users\\<USER>\\Documents\\ProjectB",
    "runtimeWorkspaceRoots": [
      "C:\\Users\\<USER>\\Documents\\ProjectB",
      "C:\\Users\\<USER>\\Documents\\ProjectA"
    ]
  }
}

The SQLite thread metadata still recorded Project A as the thread cwd.

So the persisted state was effectively:

SQLite thread cwd = Project A
workspace applied = Project A
workspace pending = Project B
thread assignment = Project B
pendingCoreUpdate = true

This inconsistent state survived application restarts and a full uninstall/reinstall.

During recovery, restoring conversation/session data alone did not reproduce the crash. Restoring the affected project/global state reproduced the startup failure. Removing the affected thread's half-applied migration state and marking the thread as projectless allowed Codex Desktop to start normally again, with both conversation history and projects restored.

This suggests an interrupted project/thread migration can be persisted without rollback/reconciliation, and that startup reconciliation can then fail the entire Codex Desktop UI rather than isolating or rolling back the affected thread.

What steps can reproduce the bug?

1. Open Codex Desktop on Windows.
2. Have an existing local thread associated with Project A.
3. Use the Codex UI to move/reassign that thread out of Project A / to another local project.
4. During the move, the project/thread migration fails.
5. Codex Desktop enters the "Something went wrong" screen.
6. Close and reopen Codex Desktop.
7. The same error screen appears immediately and the Codex UI is unusable.
8. Restart Windows. The issue persists.
9. Uninstall and reinstall the Microsoft Store ChatGPT/Codex Desktop app. The issue still persists because the affected state remains under ~/.codex.

I did not intentionally reproduce the destructive move again after recovering my data.

Post-failure inspection of the persisted local state showed that the affected thread had a half-applied workspace migration:

• SQLite thread cwd: Project A
• workspace applied.cwd: Project A
• workspace pending.cwd: Project B
• thread-project-assignments: Project B
• pendingCoreUpdate: true

Renaming ~/.codex allowed Codex to start normally again.

After restoring conversation/session data without the affected project state, Codex also started normally.

Restoring the affected project/global state reproduced the startup failure.

Removing only the affected thread's pending workspace migration/project assignment and marking it projectless allowed Codex to start normally again.

What is the expected behavior?

Moving a thread between projects, or out of a project, should behave atomically:

• If the migration succeeds, all thread/project/workspace state should be updated consistently.
• If the migration fails, Codex should fully roll back to the previous project/workspace state.

A failed move should never leave a persistent state where applied and pending workspace locations disagree and pendingCoreUpdate remains set across restarts.

On startup, Codex should safely reconcile or roll back an unfinished migration instead of failing the entire Desktop UI.

At worst, only the affected thread should be quarantined or detached from its project; the rest of Codex Desktop should remain usable.

Additional information

I backed up the original ~/.codex directory before troubleshooting and was able to isolate the failure without deleting the affected conversation.

Additional findings:

• The original local state database contained 46 thread records.
• After allowing Codex to generate a fresh ~/.codex, only 3 threads were initially registered.
• The underlying rollout/session files were still present and readable.
• Restoring valid session rollout files and corresponding threads rows from state_5.sqlite did not reproduce the startup failure.
• Restoring the old project/global state did reproduce the startup failure.
• The affected thread had a persisted half-applied project migration with:
• pendingCoreUpdate: true
• applied.cwd pointing to Project A
• pending.cwd pointing to Project B
• thread-project-assignments pointing to Project B
• SQLite thread cwd still pointing to Project A
• Removing the affected thread's stale thread-project-assignments entry and thread-workspace-state-v1:<THREAD_ID> state, then marking the thread projectless, allowed Codex Desktop to start normally again.
• I could then restore the normal local project registry without reproducing the crash.

A useful causal isolation was:

1. Fresh global/project state + restored conversations -> app starts normally.
2. Restoring the affected old project/workspace state -> startup fails again.
3. Removing only the affected thread's half-applied migration state -> app starts normally with projects and conversation history restored.

This makes the persisted unfinished workspace migration appear to be the direct trigger rather than corruption of the conversation/session data itself.

Possibly related to #35081, #34369, #23676, and #26157, but this appears to have a distinct trigger and persisted failure state: an existing thread project move leaves pendingCoreUpdate: true with mismatched applied and pending workspace state. Restoring that specific migration state reproduces the whole-app startup failure, while removing it restores normal startup.

I can provide additional sanitized excerpts if needed. I am intentionally not attaching the complete .codex-global-state.json, state_5.sqlite, auth.json, or rollout JSONL files publicly because they contain private conversation, filesystem, and account/project information.