[Windows][Codex Desktop] thread/archive regression after update: thread shuts down but archive never completes
Description
After updating Codex Desktop on Windows from version 26.810.52044 to 26.814.41407, archiving conversations stopped working.
The archive request is received by the app server and the target thread is shut down successfully, but the archive flow does not complete afterward.
The affected thread remains:
archived = 0
archived_at = NULL
rollout file still under ~/.codex/sessions
no corresponding rollout file under ~/.codex/archived_sessions
This affects multiple conversations, not just one specific thread.
I also observed a possibly related issue after the same update where an existing historical conversation disappeared from the sidebar even though its local rollout/session data still existed.
Environment
OS: Windows
Codex Desktop working version: 26.810.52044
Codex Desktop affected version: 26.814.41407
Local state database: ~/.codex/state_5.sqlite
Local log database: ~/.codex/logs_2.sqlite
Steps to reproduce
Open Codex Desktop on Windows.
Use version 26.814.41407.
Open an existing conversation.
Select the archive action.
Codex reports that the conversation cannot be archived.
Inspect the local logs and state database.
Expected behavior
The archive request should complete successfully.
A successful archive should result in behavior similar to the previous version:
thread/archive
→ thread shutdown
→ agent loop exited
→ thread listener teardown
→ thread/archived event
→ rollout moved to archived_sessions
The database should also reflect:
archived = 1
archived_at != NULL
Actual behavior
On 26.814.41407, the archive flow stops after thread shutdown / teardown.
Observed sequence:
thread/archive
→ target thread is active; shutting down
→ Shutdown submitted
→ Shutting down Codex instance
→ Agent loop exited
→ clearing thread listener during thread-state teardown
→ thread/status/changed
There is no subsequent:
thread/archived
event.
The thread remains unarchived in the local state database, and its rollout file remains under sessions.
State after failed archive
For an affected thread, the local state remains equivalent to:
archived: 0
archived_at: NULL
rollout_path: ~/.codex/sessions/.../rollout-<thread-id>.jsonl
Filesystem state:
~/.codex/sessions/
rollout-<thread-id>.jsonl EXISTS
~/.codex/archived_sessions/
rollout-<thread-id>.jsonl NOT FOUND
Log comparison
Successful archive on 26.810.52044
The older version emits the expected thread/archived event:
app-server request: thread/archive
thread <thread-id> was active; shutting down
Submission {
op: Shutdown
}
Shutting down Codex instance
Agent loop exited
clearing thread listener during thread-state teardown
app-server event: thread/archived
Immediately afterward, the archived rollout can be read from:
~/.codex/archived_sessions/rollout-<thread-id>.jsonl
Failed archive on 26.814.41407
The new version instead ends after teardown:
app-server request: thread/archive
thread <thread-id> was active; shutting down
Submission {
op: Shutdown
}
Shutting down Codex instance
Agent loop exited
clearing thread listener during thread-state teardown
app-server event: thread/status/changed
No thread/archived event follows.
Additional observations
The thread/archive RPC request itself is definitely received, so this does not appear to be a UI click-handler issue.
The target thread is also shut down successfully, so the failure appears to occur after thread teardown and before archive persistence / finalization.
There are no corresponding ERROR or WARN entries tied to the archive request in the nearby logs.
The affected version uses:
app-server/src/request_processors/thread_processor.rs:992
app-server/src/thread_state.rs:453
The previously working version used:
app-server/src/request_processors/thread_processor.rs:961
app-server/src/thread_state.rs:437
This may indicate a regression in the archive flow introduced between these builds.
Possibly related sidebar/history issue
After the same update, at least one historical conversation disappeared from the sidebar while its local session data still existed.
Local inspection showed that some rollout files were still present under ~/.codex/sessions, and corresponding thread records could still exist in state_5.sqlite.
This may or may not share the same root cause, but both issues started after the update.
Data integrity
No local database or session files were manually modified during testing.
All inspection was performed using read-only SQLite connections.
Example:
sqlite3.connect("file:" + db_path + "?mode=ro", uri=True)
Impact
Archiving is currently unusable for existing conversations on the affected build.
Because the operation shuts down the thread but does not complete archival, it also creates uncertainty around local thread/session state.
Suggested area to investigate
The regression appears to be between:
thread listener teardown
and:
thread/archived event / archive persistence
Specifically, the archive finalization path after successful thread shutdown may be exiting early or not being resumed.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Possibly related Windows regression after the same update:
After updating Codex Desktop on Windows today, Browser/Chrome control stopped working even though it worked before the update.
Observed behavior:
This suggests the update may have left a stale or mismatched Browser module/cache/config state under
%USERPROFILE%\.codexthat survives an app reinstall.This may be separate from the archive-finalization regression in this issue, but both began immediately after the same Windows desktop update, so I’m reporting it here in case the update/persistence path is shared.
A possibly related existing report is #29673 (bundled Browser/Chrome/Computer Use plugins missing/unusable on Windows after restart/reinstall).
The repeated troubleshooting also consumed a large amount of Codex weekly usage without productive project work; I have escalated that separately through OpenAI Support.
Hi @GANYANGH, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.
If you still have the affected local Codex directory, you can inspect it via:
No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.