Codex Desktop loses command/tool details after thread restore/archive, and archive restore path becomes inconsistent #26012

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.527.7698.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19044.0 x64

What issue are you seeing?

Codex Desktop loses visible command/tool details after a thread is restored, and archiving/unarchiving can produce an inconsistent rollout path error.

During the original run, the thread UI shows intermediate technical details such as command/tool rows, for example “已运行 1 条命令”, command output, file changes, and progress messages.

After the same thread is restored, either by restarting Codex Desktop or by archiving/reopening the thread, the UI only shows user/assistant text. The command/tool rows and intermediate technical details disappear.

The underlying transcript data is not lost. I verified that the raw rollout JSONL file under %USERPROFILE%\.codex\sessions\...\rollout-<thread-id>.jsonl still contains response_item entries with function_call and function_call_output. However, the restored Codex Desktop UI does not render those items.

What steps can reproduce the bug?

Feedback ID: 019e8ae1-87ee-7aa0-ba49-8c8339bdd559

1. Start a Codex Desktop local thread in coding mode.
2. Ask Codex to run a command, for example listing project files.
3. During the original run, observe that the UI shows command/tool details such as “已运行 1 条命令”, command output, and intermediate progress messages.
4. Restart Codex Desktop, or archive and reopen/unarchive the same thread.
5. Observe that the restored thread only shows user/assistant text. The command/tool rows and intermediate details are no longer visible.

Archive/unarchive related repro:

1. Archive the same thread.
2. Try to restore/open it again.
3. Codex shows: session <id> is archived. Run codex unarchive <id> to unarchive it first.
4. Then restoring from archived chats shows: failed to resolve rollout path 'C:\Users\<user>\.codex\archived_sessions\rollout-....jsonl': The system cannot find the file. (os error 2)

What is the expected behavior?

Restored threads should render the same tool calls, command outputs, file changes, and intermediate technical details that were visible during the original run.

Archiving and unarchiving should keep local thread state consistent. If a thread is active, Codex should restore it from the existing rollout path under %USERPROFILE%\.codex\sessions. If a thread is archived, the matching rollout file should exist under %USERPROFILE%\.codex\archived_sessions or the app should not try to restore from that path.

Additional information

Local state after the archive/restore error looked inconsistent:

• state_5.sqlite showed the thread as archived=0
• rollout_path still pointed to %USERPROFILE%\.codex\sessions\...\rollout-....jsonl
• that rollout file existed
• %USERPROFILE%\.codex\archived_sessions did not contain the matching rollout file
• unarchive returned no archived rollout found

I also tried reinstalling multiple recent Codex Desktop versions, but the issue still reproduced. My machine does not have Microsoft Store available, so Codex Desktop was installed from an MSIX package using PowerShell, for example:

Add-AppxPackage -Path .\*.Msix -Verbose

This suggests two related restore-path issues:

1. The restored UI does not rebuild/render function_call and function_call_output items from the raw rollout transcript.
2. Archive/unarchive can leave the UI trying to restore from archived_sessions even though SQLite says the thread is active and the real rollout file is still in sessions.

The practical impact is that any unload/restore path, including restart or archive/reopen, causes visible command/tool context to disappear from the UI. The raw transcript is still present, but Codex Desktop no longer displays the technical details that were visible during the original run.