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

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:

``text
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.
``

1. 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.