### 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: ```powershell codex resume --all ``` However, the underlying session file was still present under: ```text %USERPROFILE%\.codex\sessions ``` The session was successfully recovered only by extracting its UUID from the session file and running: ```powershel

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #32508 - #32697 - #33003 *Powered by [Codex Action](https://github.com/openai/codex-action)*

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

Open 💬 2 comments Opened Jul 15, 2026 by Varcon-dev

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Work in a project chat in the Codex desktop app.
Leave the app idle.
The app becomes unresponsive.
Close and reopen the app.
The most recent project chat is absent from the UI.
Check archived chats: the chat is absent.
Run codex resume --all: the session is absent there as well.
Inspect %USERPROFILE%\.codex\sessions: the session JSONL file still exists.
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 ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#32508
#32697
#33003

Powered by Codex Action

shleder · 14 days ago

The important detail here is that the app became unresponsive, the chat vanished from both the UI and resume --all, but the rollout remained on disk and direct UUID resume still worked. That is a strong real test for independent session discovery after an abnormal shutdown.

I’m testing Codex Rescue for this boundary. It is local-first and leaves the original rollout untouched; it cannot rebuild the Desktop sidebar, but it may help show that the session still exists and whether its persisted state is structurally safe.

If you still have the affected session, could you try:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output only is enough—no raw rollouts, databases, prompts, paths, or secrets.

https://github.com/shleder/codex-rescue