openai / openai/codex

[Windows][Desktop] Switching to Beta after the 26.820 Stable startup regression hides all legacy local threads (`chatgpt_http`)

Open
#40,909 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app bug session windows-os
Dominant language
Rust
Stars
125k
Forks
19.4k
PR merge metrics
PR metrics pending

Description

What version of the Codex App are you using?

Affected Stable installation:

  • Desktop internal version: 26.820.60940
  • Windows MSIX package: OpenAI.Codex 26.820.7780.0
  • Bundled CLI: codex-cli 0.150.0-alpha.8

Working fallback installation, where the history migration issue occurs:

  • Beta MSIX package: OpenAI.CodexBeta 26.727.4816.0
  • Beta app-server/CLI: 0.146.0-alpha.9.2
What platform is your computer?
  • Microsoft Windows NT 10.0.26200.8655, x64
  • ChatGPT account authentication
What issue are you seeing?

This is a follow-on data-compatibility regression encountered while using Beta as a workaround for #40715.

The complete failure sequence was:

  1. Stable updated to 26.820.60940 and could no longer start or resume threads because Desktop injected an invalid mcp_servers.codex_app transport. This matches #40715.

  2. Beta 26.727.4816.0 could start and run threads, so it was used as a temporary fallback against the same shared CODEX_HOME.

  3. After opening Beta, every existing local project showed No chats, and only the newly created diagnostic thread appeared under Recent.

  4. An older thread title briefly appeared, but opening it failed with:

    ChatGPT can't load config.toml, so this thread can't resume.
    Fix config.toml: Model provider `chatgpt_http` not found.
    After saving the file, reopen the thread.
    
  5. Restoring a valid model_providers.chatgpt_http definition made old threads readable by ID, but the sidebar still hid them.

This looked like complete history loss, but the underlying conversation data had not been deleted.

Forensic findings

The affected profile contained:

  • 187 rows in ~/.codex/state_5.sqlite
  • 187/187 corresponding rollout JSONL files present
  • 0 missing rollout files
  • 0 invalid JSONL records
  • 187/187 rollouts containing genuine user messages
  • 20 local projects
  • 54 explicit thread-to-project assignments

Before recovery:

  • 186 legacy local thread rows had model_provider = 'chatgpt_http'
  • The single newly created, visible Beta thread had model_provider = 'openai'
  • Direct thread reads by ID succeeded after restoring the provider definition
  • The app's actual recent-thread/list path returned only the one openai local thread and excluded all chatgpt_http rows, even with modelProviders: null

The decisive canary test was changing only one backed-up legacy thread's state index from chatgpt_http to openai. That exact thread immediately appeared in the real Desktop thread-list response and its existing content remained readable. Migrating the remaining legacy state/catalog provider indexes restored the complete local history.

Two additional backward-compatibility gaps were observed during recovery:

  • All legacy state rows had has_user_event = 0 even though every rollout contained real user messages.
  • Existing project assignment objects did not contain the newer required pendingCoreUpdate boolean, so the Beta renderer ignored the old assignments until that field was added with false.

These two corrections alone did not restore the sidebar. The final blocker was the legacy chatgpt_http provider value being excluded by the current list path.

Steps to reproduce

This requires an existing Windows profile with local threads created under the older provider identifier.

  1. Have existing local Codex Desktop threads whose state rows use model_provider = 'chatgpt_http'.
  2. Update Stable to the affected 26.820.x build and encounter #40715.
  3. Install/open Beta 26.727.4816.0 against the same shared CODEX_HOME.
  4. Create one new Beta thread.
  5. Restart Beta.
  6. Observe that the new openai thread is visible, while old projects display No chats and old local history is absent from Recent.
  7. Read an old thread directly by ID: its rollout and content still exist.
  8. Change one backed-up legacy thread index from chatgpt_http to openai and query the app's thread list again.
  9. Observe that the canary thread now appears.
What is the expected behavior?
  • Switching between supported Stable and Beta builds must not make intact local history appear deleted.
  • Legacy provider identifiers should be migrated or treated as compatible aliases when the state database is opened.
  • Missing newer fields in persisted UI/project state should receive backward-compatible defaults.
  • If a thread cannot be listed or resumed, Desktop should surface an actionable compatibility error instead of silently showing No chats.
  • Updating one app channel should not leave the shared CODEX_HOME in a state that the other channel cannot understand.
Recovery notes for affected users

The safest first response is:

  1. Do not clear application data, uninstall with data removal, or delete ~/.codex.
  2. Fully exit Desktop.
  3. Back up config.toml, .codex-global-state.json, state_5.sqlite, sqlite/codex-dev.db, and the sessions directory.
  4. Verify that rollout JSONL files still exist before concluding that history is lost.

On this installation, recovery required migrating internal provider/catalog metadata and rebuilding visibility/project metadata from verified rollout files. This is an unsupported internal repair and should not be presented as a general-purpose SQL recipe without backups and validation. An official repair/migration command would be much safer.

Requested fix
  1. Fix the Stable mcp_servers.codex_app regression tracked in #40715.
  2. Add a state migration from legacy chatgpt_http thread/catalog rows to the currently supported provider identifier, or preserve chatgpt_http as a readable alias.
  3. Recompute has_user_event from valid rollout events when importing legacy state.
  4. Default missing pendingCoreUpdate values to false when parsing older project assignments.
  5. Add a supported history-repair command that validates rollouts, backs up state, and rebuilds local indexes without deleting conversation data.
  6. Add a regression test where Stable and Beta sequentially open the same populated CODEX_HOME.
Additional information
  • Database integrity checks passed after recovery.
  • No rollout/session files were deleted or regenerated.
  • The full recovery restored all 187 local threads and all 54 project assignments.
  • Screenshots from before and after recovery are available if maintainers need them.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by inspecting the state_5.sqlite and sqlite/codex-dev.db data alongside the sessions rollout JSONL files, then trace the Desktop thread-list path and persisted project-assignment parsing. Done means supported Stable and Beta builds preserve legacy local history, apply compatible defaults and provider migration, surface actionable errors, and include a regression test for shared CODEX_HOME.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, sqlite
Domain
databases, desktop, operating-systems, testing-qa
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.