[Windows][Codex Desktop] thread/archive regression after update: thread shuts down but archive never completes

Open 💬 3 comments Opened Aug 18, 2026 by GANYANGH
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 10 days ago

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

  • #39130

Powered by Codex Action

hattimon · 10 days ago

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:

  • Built-in Browser fails before opening a page because the integrity check reports that the trusted/expected Browser module hash does not match the Browser module currently installed/cached locally.
  • Chrome extension is installed and shown as enabled under Settings → Computer use, but Codex still cannot connect to/control Chrome and stops before reading/selecting browser tabs.
  • A full uninstall/reinstall of the ChatGPT/Codex desktop app did not fix it.
  • Reinstalling the Chrome plugin/extension did not fix it.
  • The integrity setting was not left weakened; the original configuration was restored after a brief test of the suggested hash change did not solve the problem.
  • No browser/Cloudflare changes were made because control never initialized successfully.

This suggests the update may have left a stale or mismatched Browser module/cache/config state under %USERPROFILE%\.codex that 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.

boombx403-byte · 9 days ago

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:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.