openai / openai/codex

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

Open
#39,146 3 comments 6 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

app app-server bug windows-os
Dominant language
Rust
Stars
125k
Forks
19.5k
PR merge metrics
PR metrics pending

Description

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-.jsonl

Filesystem state:

~/.codex/sessions/
rollout-.jsonl EXISTS

~/.codex/archived_sessions/
rollout-.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 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-.jsonl
Failed archive on 26.814.41407

The new version instead ends after teardown:

app-server request: thread/archive

thread 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing app-server/src/request_processors/thread_processor.rs around lines 992 and 961, then app-server/src/thread_state.rs around lines 453 and 437. Trace the archive path from thread shutdown and listener teardown to the missing thread/archived event and archive persistence. Done means the request completes, the database has archived = 1 with archived_at set, and the rollout moves to archived_sessions.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
56/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.