Repository navigation
Codex Desktop should preserve local history visibility and continuation across providers/accounts #20004
Description
Codex Desktop should preserve local history visibility and continuation across providers/accounts
What version of the Codex App are you using?
Codex Desktop on Windows. I can provide the exact build from the About dialog if needed.
What subscription do you have?
Multiple paid OpenAI / ChatGPT accounts, plus custom OpenAI-compatible API providers configured through a provider/account switcher.
What platform is your computer?
Windows, using Codex Desktop with the default local Codex home under %USERPROFILE%\.codex.
What issue are you seeing?
Switching between OpenAI accounts and OpenAI-compatible custom providers makes local Codex Desktop history unreliable:
- Old local sessions disappear from the Codex Desktop project/history view after switching provider/account.
- Local rollout files still exist under
%USERPROFILE%\.codex\sessionsand%USERPROFILE%\.codex\archived_sessions. - The visible provider metadata can differ between sessions, for example
openaiandcustom. - Existing third-party sync tools can make the sessions visible again by rewriting local metadata, but this is risky and can leave the user unsure whether history was actually lost.
- Many sessions contain
encrypted_content; after switching provider/account, visible sessions may still fail to continue if encrypted history is sent to the wrong account/provider.
I understand that #15219 was closed by #19287, which restores the persisted model_provider during resume. That seems to address one important continuation path. However, the broader Desktop user problem remains:
- Local history discovery/project-side visibility should not depend on the currently active provider/account.
- Codex Desktop should make it clear which provider/account owns a persisted encrypted thread.
- Resuming a thread should either route to the original provider/account automatically or show an actionable UI error instead of pushing users toward local SQLite/JSONL rewrites.
- There should be an official repair/diagnostic path for local history indexes when Codex Desktop fails to show sessions that still exist on disk.
Local evidence
On my machine, a local diagnostic script reports:
Codex home: C:\Users\ShenKongDiao\.codex
Current provider: openai
Rollout files: 20
Rollout providers: {'openai': 12, 'custom': 8}
Encrypted content providers: {'openai': 12, 'custom': 8}
SQLite thread indexes:
state_5.sqlite: threads=20, providers={'custom': 8, 'openai': 12}
logs_2.sqlite: present, backup-only
This means the sessions are physically present, but provider/account switching can make them disappear from normal Desktop history/project surfaces. All detected sessions contain encrypted_content, so simply rewriting model_provider metadata is not a safe complete migration.
Steps to reproduce
- Use Codex Desktop with the built-in OpenAI provider/account and create local project sessions.
- Switch to another OpenAI account or to a custom OpenAI-compatible provider.
- Reopen Codex Desktop and inspect the local project/history view.
- Observe that sessions from the previous account/provider may be hidden, even though rollout files and local SQLite metadata still exist.
- If local metadata is rewritten to force visibility, try continuing an old encrypted session from a different account/provider.
- Observe that continuation can still fail because encrypted history belongs to the original provider/account context.
Expected behavior
- Codex Desktop local history/project views should list local sessions across providers/accounts by default, or provide a clear filter that defaults to "all local sessions".
- Each session should preserve and display its original provider/account identity.
- Resuming should use the persisted provider/account context when possible.
- If a session cannot be continued because the required provider/account credential is unavailable, Codex should show a precise error and offer recovery options instead of silently hiding the thread.
- Users should not need to rewrite
%USERPROFILE%\.codex\sessionsor SQLite metadata to recover history visibility.
Actual behavior
- Provider/account switching makes history appear to disappear.
- Users are pushed toward third-party tools or hand-written scripts that mutate local rollout JSONL and SQLite metadata.
- Those workarounds can restore list visibility but cannot safely solve encrypted-content continuation across accounts/providers.
Related issues / PRs
- Switching model_provider hides existing local sessions from resume/fork/history #15494: Switching
model_providerhides existing local sessions from resume/fork/history. Closed as not planned, but it describes the visibility/discovery side of this problem. - thread/resume does not restore model_provider from persisted metadata — breaks cross-provider conversation continuation #15219: Resume did not restore persisted
model_provider, causinginvalid_encrypted_content. - Restore persisted model provider on thread resume #19287: Merged fix for restoring persisted model provider on resume.
Suggested official fix
Please consider treating this as two separate product behaviors:
- History discovery: Desktop project/history views should discover local sessions across providers/accounts without requiring metadata rewrites.
- Continuation: Resume should use the persisted provider/account identity for encrypted sessions, and if credentials are unavailable, show a recoverable UI state.
An official diagnostic command or Desktop repair action would also help, for example:
codex doctor history
codex repair-history-index
These commands could verify rollout files, SQLite thread indexes, encrypted-content ownership, workspace root matching, and project visibility without changing auth data.
Additional information
I am not requesting that encrypted content be decrypted or migrated across accounts. I am asking for official history visibility and continuation semantics so local sessions do not appear lost after normal provider/account switching.
Activity
github-actions commentedon Apr 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
paulhshort commentedon Apr 29, 2026
Would love to see this fixed. I tried to use one of those 3rd party tools (codex-multi-auth from gh) and it resulted in my work chatgpt Pro account to get deactivated by their automated system. Very frustrating all around.
For context, I was originally using Azure as provided, and then shifted to chatgpt pro accounts(one personal account I pay for and one my employer was paying for)
Wangnov commentedon May 22, 2026
This sounds very close to the provider-bucket visibility problem that
codex-threadripperwas built for.Project: https://github.com/Wangnov/codex-threadripper
It checks how Codex threads are distributed across
model_providervalues instate_5.sqliteand the rollout JSONL metadata, then can reconcile them so Codex Desktop /codex resume/ app-server clients see the same local history after provider switches.Suggested safe flow:
It writes backups before mutating local state. Still, please back up
~/.codexfirst, especially if your sessions contain important work.Important caveat: this is an unofficial workaround for local history visibility. It does not migrate encrypted conversation ownership across accounts/providers, and it should not replace an official Codex fix for provider-aware history listing/resume behavior.
nostitos commentedon Aug 23, 2026
Adding my support, with an even simpler reproduction on macOS: sign out of Codex Desktop. The app becomes essentially empty and gives no read-only access to existing local tasks, even though the local database and session files remain on disk. I also verified locally that the app-server can still enumerate those threads while it reports no signed-in account, which shows this is a GUI/auth policy boundary rather than the history being unavailable.
Authentication should gate model/API actions and resuming encrypted content—not read-only access to local task metadata and transcripts. At minimum, Codex should provide a signed-out/offline “All local tasks” view, identify the owning account/provider, and mark continuation as unavailable until the appropriate account is signed in.
Hiding all locally stored history on logout creates a false impression of data loss and pushes users toward JSONL/SQLite tools or unofficial viewers. Please treat local history visibility as independent of account authentication.
Audacity88 commentedon Sep 2, 2026
A Desktop/paginated-history follow-on is worth noting for local recovery tools. Removing provider-bound encrypted reasoning shortens the source rollout. On paginated tasks, that can leave stale
thread_history_*projections and descendanthistory_base.end_byte_offsetvalues pointing at the wrong boundary, causing truncated UI history orinvalid paginated history lineageafter the original replay error is gone.A safer recovery preserves visible and tool records, stashes removed reasoning, rebases history offsets from ordinals transitively, resets only affected projections, invokes Codex's own rollout migration, and then re-audits lineage because migration can shift subsequent offsets.
We packaged that backup-first workflow with synthetic regression coverage here: https://github.com/EyrieCommander/codex-skills/tree/master/skills/codex-history-repair
Its scope is intentionally narrow: top-level encrypted reasoning records and paginated Desktop history. It does not claim to repair nested compactions, encrypted function/tool outputs, malformed JSONL, or duplicate ordinals. Codex and database watchers must be fully closed before mutation.
OriyukiAkari commentedon Sep 4, 2026
I tested the continuation half of this issue while investigating #17541 and #40314.
Tested implementation:
OriyukiAkari@926c1d1
This does not address history discovery/sidebar visibility. It specifically addresses what happens after the same existing thread is explicitly resumed through a different model provider.
The approach does not rewrite the rollout JSONL or SQLite projection. Provider-bound history remains persisted in its original form. A portability boundary is instead established in core, and only the prior non-portable material is sanitized when constructing requests for the replacement runtime:
Reasoning.encrypted_contentis removed while plaintext summary/content is preservedCompaction/ContextCompactionitems are droppedKeeping this request-time rather than destructively editing the rollout also means the source rollout's record layout/offsets are not changed as part of provider migration.
For histories with no surviving previous real turn, loaded-history provider provenance is tracked separately and can fall back to
SessionMeta.model_provider. A sticky portability marker on survivingTurnContextItems carries the state across reconstruction/restart without fabricating a previous turn.I validated this with an existing Desktop/app-server thread whose persisted provider was
openai, explicitly resuming the same thread ID with effective providercustom.Before the change, continuation failed when provider-bound encrypted history reached the replacement runtime.
After the change:
The original encrypted history remained in the rollout throughout the test; no JSONL or SQLite repair was performed.
So this only addresses the safe-continuation side of the issue. The Desktop visibility/discovery behavior described here still needs a separate product/UI solution, as does the supported provider-selection/recovery UX discussed in #40314.
The fuller root-cause and regression details are in #17541.