Archived local sessions hidden and fail to resume after switching auth/provider

What happened

After switching local Codex configuration from an API/custom provider setup to ChatGPT login mode, old local chat history appeared to be gone. The underlying rollout JSONL files still existed, but direct resume failed for an old session ID:

codex resume 019d0250-8664-7713-bfde-19a0e1110b3f
Error: Failed to resume session from ~/.codex/archived_sessions/rollout-2026-03-18T21-58-44-019d0250-8664-7713-bfde-19a0e1110b3f.jsonl

The data was not deleted. The session file was valid JSONL and the state database passed integrity checks. The problem appears to be a local state/archive migration or compatibility issue: archived sessions are hidden from the normal history and direct codex resume <id> fails when the state row points at ~/.codex/archived_sessions/....

Environment

• Codex CLI: codex-cli 0.124.0
• Current auth mode: ChatGPT login
• Old session metadata: cli_version=0.115.0-alpha.27, source=vscode, originator=Codex Desktop, model_provider=cliproxyapi, model=gpt-5.4
• Current config uses ChatGPT login and a newer default model (gpt-5.5)

Local evidence

For the affected session, state_5.sqlite had a row like:

id=019d0250-8664-7713-bfde-19a0e1110b3f
rollout_path=~/.codex/archived_sessions/rollout-2026-03-18T21-58-44-019d0250-8664-7713-bfde-19a0e1110b3f.jsonl
archived=1
source=vscode
model_provider=cliproxyapi
cli_version=0.115.0-alpha.27
model=gpt-5.4

Checks performed:

jq empty < rollout.jsonl                                      # passed
sqlite3 ~/.codex/state_5.sqlite "pragma integrity_check;"     # ok
sqlite3 ~/.codex/logs_2.sqlite "pragma integrity_check;"      # ok

The affected install had many archived sessions in this state:

select archived, count(*) from threads group by archived;
0|1297
1|254

Expected behavior

Changing auth/provider configuration should not make local history appear lost. Archived local sessions should either:

1. remain discoverable in history, or
2. be recoverable via codex resume <id>, or
3. produce a clear migration/recovery message instead of a generic failed-resume error.

Actual behavior

Old chats appear missing from history after the auth/provider change, and direct resume of a valid archived rollout fails with:

Error: Failed to resume session from ~/.codex/archived_sessions/rollout-...jsonl

Workaround found locally

A manual repair against a copied Codex home worked:

1. Copy archived rollout files back into the normal ~/.codex/sessions/YYYY/MM/DD/ layout.
2. Update each affected thread row in state_5.sqlite to point to that active sessions path.
3. Set archived=0 and archived_at=NULL.

After doing this in a disposable Codex home copy, archived remaining became 0, DB integrity stayed ok, and codex resume --no-alt-screen 019d0250-8664-7713-bfde-19a0e1110b3f opened the old conversation successfully.

Why this seems like a Codex bug

The archived rollout files are still present and parse correctly. The failure is not data loss or JSONL corruption. It looks like newer Codex versions/login-mode history handling do not gracefully handle older Desktop/API-provider sessions that are marked archived and stored under archived_sessions.

A built-in migration, an unarchive all, or better resume fallback from archived rollouts would prevent users from thinking their chat history was deleted.