Codex Chats Disappear when Switching Providers

Keep your local sessions visible when moving Codex to DeepSeek V4 Flash through Fireworks and back again

When I switched Codex Desktop to Fireworks-hosted DeepSeek V4 Flash, all my project folders were there, but all the chat conversations were not visible.

I had switched Codex Desktop to DeepSeek V4 Flash through Fireworks when my ChatGPT subscription hit 2% remaining. The change to ~/.codex/config.toml was small: model_provider moved from openai to fireworks. When I reopened the app, my folders were still there but every ChatGPT-provider conversation was gone from the sidebar. The rows in state_5.sqlite and my rollout files stayed on disk. A WAL-safe SQLite backup and one update to the model_provider table restored the conversations to the sidebar on my machine.

Why the conversations disappeared

Codex keeps sessions in separate groups by provider. DeepSeek’s Codex integration page says sessions created through an official ChatGPT subscription and sessions created through a third-party API are kept apart, and only the group matching the current configuration is shown. Nothing is deleted.

The session list is filtered by model_provider. The app-server protocol exposes ThreadListParams.model_providers as an optional array of strings, and the state-layer query applies a provider clause when the caller supplies a nonempty list:

AND threads.model_provider IN (...)

Each thread carries the provider ID it was created under. Mine said openai; after the switch, the app asked for fireworks, and the openai rows no longer matched. A Windows report recorded the same current-provider-only behavior.

On my machine, the local rows and rollout files stayed present while the sidebar view changed. The partitioning by provider seemed like an artificial and unnecessary limitation when all the conversations and metadata were stored locally.

The bridge script

The fix is one small script, ~/.codex/bridge-providers.sh. It reads the active provider from config.toml, takes a timestamped backup, and merges every thread into that provider so the app shows all conversations:

#!/usr/bin/env bash
# Merge all threads into the currently active provider so the app shows
# conversations from every provider regardless of model_provider config.
# Run BEFORE the app loads after switching providers.
set -euo pipefail

STATE=~/.codex/state_5.sqlite
CFG=~/.codex/config.toml
PROVIDER=$(awk '/^model_provider[[:space:]]*=/{gsub(/[ "\t]/,"",$3); print $3}' "$CFG" | head -1)
PROVIDER=${PROVIDER:-openai}

if [[ ${1:-} == "--dry-run" ]]; then
  sqlite3 -readonly "$STATE" "SELECT model_provider, count(*) FROM threads GROUP BY 1 ORDER BY 2 DESC"
  echo "would set all threads to: $PROVIDER"
  exit 0
fi

sqlite3 "$STATE" ".backup '$STATE.bak-$(date +%Y%m%d-%H%M%S)'"
# backup; rotate to keep 5 most recent backups
ls -1r "$STATE".bak-* 2>/dev/null | tail -n +6 | xargs -r rm -f
sqlite3 "$STATE" "UPDATE threads SET model_provider = '$PROVIDER';"
sqlite3 "$STATE" "SELECT model_provider, count(*) FROM threads GROUP BY 1;"
echo "done: all threads now show under '$PROVIDER'. Backup saved alongside state_5.sqlite."

The order matters. Quit the Codex desktop app and the CLI first, switch the provider in config.toml, run the script, then reopen the app. A --dry-run flag prints the per-provider counts and the target provider before any change.

The script includes a thorough backup. SQLite keeps recent writes in a sidecar -wal file, so a plain file copy can miss data. The script uses SQLite’s online backup (.backup), which merges the WAL into a consistent snapshot; I confirmed PRAGMA integrity_check returns ok on the backup. Backups rotate to the five most recent.

The output before and after the update shows the merge: all threads now carry the active provider, and the total row count is unchanged.

A single UPDATE bridges the partition with zero data migration: no rollout file moves and no thread row is copied. The statement rewrites the provider label that Codex uses when it decides which rows to list.

A conversation that resumes poorly across providers or accounts can still fail even though it is visible again, so I run a resume test on a long session after each bridge. A community report documented exactly that gap, and a related request for all-provider discovery was closed as not planned.

Leaving the beaten path

Codex supports custom providers, so the Fireworks route used a documented configuration surface. The hidden history still showed that I was off the app’s beaten path, using a case that may not be central to the model and harness team’s priorities. A provider-independent harness would treat the provider as a runtime choice while keeping local discovery independent from that choice.

I have become heavily invested in Codex this year because of how OpenAI engages with its developer ecosystem, the advances in model capabilities and pricing, and innovative Codex app features. I wasn’t ready to give up on it just yet, and this bridge script makes every switch cheap. Provider-partitioned visibility gets in the way of a tool whose conversations live on my disk.