Codex app loses latest project chat from UI/index after restart, but session remains recoverable by direct session ID

Open 💬 1 comment Opened Jul 15, 2026 by Varcon-dev

Summary

After the Codex desktop app became unresponsive while idle, I closed and reopened it. The latest chat for an important project disappeared from the app UI.

The chat was not visible in archived chats and was also missing from:

codex resume --all

However, the underlying session file was still present under:

%USERPROFILE%\.codex\sessions

The session was successfully recovered only by extracting its UUID from the session file and running:

codex resume <SESSION_ID>

Environment

  • Platform: Windows
  • Shell used for recovery: PowerShell
  • Product: Codex desktop app with graphical interface
  • Codex CLI was used only for recovery
  • App/CLI version: not recorded

Steps to reproduce

  1. Work in a project chat in the Codex desktop app.
  2. Leave the app idle.
  3. The app becomes unresponsive.
  4. Close and reopen the app.
  5. The most recent project chat is absent from the UI.
  6. Check archived chats: the chat is absent.
  7. Run codex resume --all: the session is absent there as well.
  8. Inspect %USERPROFILE%\.codex\sessions: the session JSONL file still exists.
  9. Run codex resume <SESSION_ID> using the UUID from the file: the session opens successfully.

Expected behavior

A valid session present in the local sessions directory should remain visible in the desktop app and should be listed by codex resume --all after restarting the application.

Actual behavior

The session file remains intact, but the session disappears from both the desktop UI and the resume --all picker. It is recoverable only by passing the exact session UUID directly.

Impact

This creates the appearance of permanent data loss for important project conversations. Users may assume the chat has been deleted even though the transcript still exists locally.

Additional observation

This appears consistent with an indexing or metadata synchronization failure after an abnormal app shutdown. A startup integrity check or a safe “rebuild session index” action could prevent this situation.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗