Codex Desktop external-agent import makes imported chats look new and hides existing project history
What version of the Codex App are you using (From “About Codex” dialog)?
26.429.61741
What subscription do you have?
Pro
What platform is your computer?
macOS / Darwin arm64
What issue are you seeing?
Codex Desktop's "Import configuration from another agent" / external agent import flow imported third-party agent chats into the main Codex history as if they were created today, which displaced native Codex project history and made several existing projects appear to have "No chats".
This was extremely disruptive because the UI looked like prior Codex work had been lost. The local Codex data was still present, but the Desktop sidebar/project list was polluted and filtered in a way that hid existing native chats for projects that did not receive imported chats.
Observed behavior:
- The import created 50 new Codex thread records from external agent history.
- All 50 imported threads were written with
created_at/updated_atequal to the import time, not the original conversation time. - The imported threads appeared at the top of recent/project history as if they were brand-new Codex conversations.
- Projects that did not receive imported external-agent chats showed "No chats", even though their native Codex threads still existed in
~/.codex/state_5.sqliteand their rollout.jsonlfiles still existed under~/.codex/sessions/. - Marking the imported threads as archived directly in
state_5.sqlitewas not enough. On app restart, Codex reindexed the imported.jsonlfiles still present under~/.codex/sessions/...and reactivated the imported threads. - The durable local workaround was to move the 50 imported rollout
.jsonlfiles out of the active~/.codex/sessions/tree, remove their entries fromsession_index.jsonl, and archive their thread rows again.
Local evidence from the incident:
- Import registry:
~/.codex/external_agent_session_imports.json - Imported records: 50
- Import window: approximately 2026-05-06 13:18:44 to 13:19:02 local time
- Imported target projects:
- 41 threads into one existing local workspace
- 6 threads into the home workspace
- 3 threads into another existing project
- Existing native projects affected by the sidebar displaying "No chats" still had active rows and files, for example:
- one project had 9 active native Codex chats
- another workspace had 12 active native Codex chats
- another project had 3 active native Codex chats
- Those native rollout files existed on disk and matched the
rollout_pathvalues in SQLite.
The external import also modified user configuration by enabling a third-party marketplace/plugin, but this issue is specifically about history/sidebar corruption and lack of a safe undo path.
What steps can reproduce the bug?
- Use Codex Desktop on macOS with existing native Codex project history across multiple projects.
- Open Settings and click the prompt similar to "Import configuration from another agent" / "Codex found useful configuration in another local agent app".
- Confirm/import the external agent configuration/history.
- Observe that imported external-agent chats appear in Codex recent/project history as if they were created at the import time.
- Observe that some existing projects that did not receive imported external-agent chats show "No chats" in the sidebar, despite having native Codex threads on disk/in SQLite.
- Inspect local state:
~/.codex/external_agent_session_imports.jsonlists imported thread IDs.~/.codex/state_5.sqlitecontains both the imported threads and the pre-existing native Codex threads.- pre-existing native
rollout_pathfiles still exist under~/.codex/sessions/.
- Try to archive only the imported threads in SQLite.
- Restart Codex Desktop.
- Observe that the imported threads become active again because their imported
.jsonlfiles remain under the active~/.codex/sessions/tree and are reindexed.
What is the expected behavior?
The external agent import flow should not make existing Codex history appear lost.
Expected behavior:
- Imported external-agent chats should preserve their original conversation timestamps, or at least be clearly marked and grouped by import source/date instead of being inserted into recent history as brand-new chats.
- Imported chats should not displace or hide native Codex project chats.
- Projects with existing native Codex threads should never display "No chats" just because they did not receive imported external-agent chats.
- The import should have a clear undo/revert action.
- Archiving imported threads should persist across app restarts.
- Reindexing should respect archived/imported state and should not silently reactivate imported history from files under
~/.codex/sessions/. - Ideally, external-agent imports should be quarantined or staged before being merged into the normal Codex session tree.
Additional information
This was user-visible as apparent data loss and required manual local repair.
Manual workaround used:
- Back up
~/.codex/state_5.sqlite,session_index.jsonl, andexternal_agent_session_imports.json. - Use
external_agent_session_imports.jsonas the source of truth for the 50 imported thread IDs. - Move the corresponding imported rollout
.jsonlfiles out of~/.codex/sessions/into a recovery/quarantine folder. - Remove the imported IDs from
session_index.jsonl. - Mark the imported thread rows as archived in
state_5.sqlite. - Verify after waiting/restarting that imported active count remains 0 and native project chats are still present.
Related but not exact issues found before filing:
- openai/codex#21076: Recent conversation history hidden/stale despite local DB containing threads
- openai/codex#18364: Mac app hides older local conversations after update because bogus sessions flood recent history
- openai/codex#17354: Recent thread history wiped in app, present in CLI
- openai/codex#14389: Desktop App does not display existing local sessions from shared CODEX_HOME
This report is specifically about the external-agent import flow creating normal active Codex threads with import-time timestamps and the app reindexing/reactivating those imported threads on restart.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗