Could not archive conversation

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

Codex Desktop MSIX: 26.814.5167.0

What subscription do you have?

Pro

What platform is your computer?

Windows 25H2 x64, build 26200.9168

What issue are you seeing?

I can reproduce a stronger variant of this issue after a recent Windows Desktop update.

Environment:

Windows 25H2 x64, build 26200.9168
Codex Desktop MSIX: 26.814.5167.0
App-server client version in logs: 26.814.41407
codex-cli: 0.148.0-alpha.15

Regression evidence:

At 14:30:54, client 26.810.52044 successfully handled thread/archive: a thread/archived event was emitted and the rollout file moved into ~/.codex/archived_sessions.
thread/unarchive also succeeded at 14:31:04.
After the client updated to 26.814.41407, archive attempts at 14:32:19 and 14:32:44 entered thread/archive, but the last recorded action was:
clearing thread listener during thread-state teardown
No thread/archived event followed.
Both conversations remained in ~/.codex/sessions.
list_threads still returned both conversations as active/notLoaded, while list_archived_threads returned an empty list.

Expected:
The conversation is moved to archived storage, removed from the active task list, and appears under Archived Conversations.

Actual:
The archive request starts and tears down the thread listener, but never completes or persists the archived state.

This looks like a regression in the archive/thread-state teardown path, rather than only the sidebar reconciliation problem originally reported in #25541.

What steps can reproduce the bug?

open a new conversation, then try to archive it

What is the expected behavior?

the conversation should be archived

Additional information

No response

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

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

Powered by Codex Action

Windows x64 confirmation on the same MSIX build: 26.814.5167.0.

After updating on 2026-08-18, I have at least three affected local Codex conversations:

The conversations remain visible in the sidebar.
At least one cannot be reopened/continued and shows thread not found.
Archiving fails, so the mandatory archive-before-delete flow also prevents cleanup.

A direct archive attempt returns:

failed to archive session: thread-store internal error:
failed to archive thread: The system cannot find the file specified. (os error 2)

One affected thread ID is:
01a013b2-9800-75d0-ae83-35e9dbc50a8e

The workspace directory for that thread still exists, and the task record remains readable via the local task listing; nevertheless, archive cannot complete. I have not reset the app, deleted .codex, or removed the workspace, to avoid destroying potentially recoverable history.

This is an end-user confirmation of the Windows 26.814 archive regression described here, with the additional failure mode that the incomplete archive operation leaves threads neither archivable nor deletable.

Affects me too, e.g. thread IDs 01a01096-490e-79e3-ae46-2de9bd6bc293, 01a0148c-d321-7fc1-88df-217665aec55a.

Follow-up after installing the newer Windows package: the issue is still reproducible, and I collected additional redacted diagnostics that may help narrow down the failing layer.

Environment

Codex Desktop MSIX: 26.814.5517.0 (x64)
Windows 25H2 x64, build 26200.9168
App-server reported version: 0.148.0-alpha.15
Runtime release recorded in the desktop log: 26.814.41957
Test time: 2026-08-19, approximately 09:29–09:36 UTC

Affected threads

The same failure is reproducible for three separate local threads:

01a013b2-9800-75d0-ae83-35e9dbc50a8e
01a013b5-6c17-7771-81f6-7a16770fe0a5
01a017b3-1f3b-7813-aa64-81ce16f194b3

Local task titles, workspace paths, account details, and conversation contents are intentionally omitted.

Backend response

Archive requests from the normal recent-tasks menu reached thread/archive, then failed in approximately 84–151 ms with the same response for all three threads:

errorCode=-32603
failed to archive session: thread-store internal error:
failed to archive thread: 系统找不到指定的文件。 (os error 2)

This is therefore not only a sidebar/UI reconciliation failure: the app-server returns an explicit archive error.

Read/archive state mismatch

Immediately after the failed archive attempts:

thread/read succeeds for all three threads.
thread/turns/list succeeds for all three threads.
All three remain in the active thread list with status notLoaded.
None appears in the archived thread list.
The database rows remain archived = 0 and archived_at = NULL.
For 01a013b2-9800-75d0-ae83-35e9dbc50a8e, attempting turn/start separately fails with:
```
errorCode=-32600
thread not found: 01a013b2-9800-75d0-ae83-35e9dbc50a8e
```

So this thread can be listed and read, but cannot be continued or archived.

Important filesystem check

Using a read-only inspection of state_5.sqlite:

Each of the three thread rows has an absolute rollout_path.
The exact source rollout JSONL referenced by each database row currently exists.
All three files are non-empty.
None of the three source files is in archived_sessions.

This suggests that os error 2 is not simply caused by the primary source rollout JSONL being absent. It may instead involve another path used by the archive transaction, a stale secondary reference, or inconsistent migration/index state. That is an inference; the logs do not identify which internal path produced the error.

No application reset, database edit, cache deletion, manual file move, or downgrade was performed. The affected data has been left intact for further diagnosis.

I reproduced this on Windows with the Codex desktop app package:

Package: OpenAI.Codex
Version: 26.814.5517.0
Architecture: x64
Cloud ChatGPT conversations were not tested; this affects local Codex tasks.

Symptom

Archiving some completed Codex tasks fails with:

thread-store internal error: failed to archive thread:
The system cannot find the file specified. (os error 2)

The rollout file has not actually been deleted.

Root cause

In %USERPROFILE%\.codex\state_5.sqlite, affected rows in the threads table have a rollout_path using the Windows extended-length path form:

\\?\C:\Users\<user>\.codex\sessions\YYYY\MM\DD\rollout-....jsonl

Unaffected rows use:

C:\Users\<user>\.codex\sessions\YYYY\MM\DD\rollout-....jsonl

The file exists and is accessible using both representations. However, the archive implementation fails when rollout_path contains the \\?\ prefix.

This is not merely old corrupted data. Local tasks that are opened or actively running can write the extended-length path back into the database. Consequently:

A path can be normalized manually.
Archiving then succeeds.
Opening or running that task can restore the \\?\ path.
Archiving fails again.

This explains why some chats archive successfully while others do not.

Reproduction

Create and run a local Codex task on Windows.
Wait for the task to complete.
Inspect its threads.rollout_path in %USERPROFILE%\.codex\state_5.sqlite.
If the value begins with \\?\, try archiving the task.
Archiving fails with os error 2, although the rollout file exists.
Back up the database and remove only the \\?\ prefix from that row.
Retry archiving: it succeeds.
Restoring or unarchiving also succeeds.

I verified the workaround through multiple archive → restore cycles.

Temporary workaround

With Codex fully closed and after backing up state_5.sqlite, normalize affected local-drive paths from:

\\?\C:\...

to:

C:\...

Editing the database while Codex is running is not durable because loaded tasks can write the extended path back.

Suggested product fix

The thread store should treat ordinary Windows paths and extended-length Windows paths consistently.

Suggested changes:

Normalize rollout_path before persisting it or before archive/unarchive filesystem operations.
Ensure the source and destination paths use compatible representations before moving the rollout file.
Avoid overwriting a normalized database value with a stale extended-path value held in memory.
Add a startup migration for existing affected threads.rollout_path rows, after confirming the corresponding file exists.
Add Windows regression coverage for:
- C:\... rollout paths;
- \\?\C:\... rollout paths;
- active → completed → archived tasks;
- archive → restore;
- reopening a task after path normalization.

The important detail is that \\?\C:\... is a valid Windows path. The bug appears to be inconsistent handling of the two valid path representations inside the archive operation.

@weijunswj

I have the same error, although @weijunswj 's suggestion did not work for me - none of my threads.rollout_path began with \\?\. I sent feedback ID 01a019ee-a09c-71d1-bc17-89da41325b0c. When I try to type anything into that thread's chat, I see this error: thread not found: .....

Feedback ID 01a020f1-07ab-7c11-b993-7e37053023b7 - getting this error as well. My chat list is just becoming messy.

It'll be nice if this was resolved

Powershell script to archive. Can't guarantee that it won't break the local state (at least it's not for now) so use it at your own risk.

This changes DB state only, so run this, then click archive in the UI. At least my old unarchivable convo has disappeared from my view (I rarely dig them out, and if I do, I refer them by UUID in a new conversation instead).

Usage:

.\Archive-Codex.ps1 "codex://threads/THREAD-ID"

.\Archive-Codex.ps1 -Thread @(
  "codex://threads/THREAD-ID-1"
  "codex://threads/THREAD-ID-2"
)

Requires python 3 and sqlite.

Archive-Codex.zip

Follow-up from another Windows x64 installation: this remains reproducible on a newer Codex Desktop package, even after a full desktop restart.

Environment:

Codex Desktop MSIX: 26.818.2441.0
codex-cli: 0.146.0
Local Codex task (not a cloud ChatGPT conversation)

Reproduction:

The normal Archive action failed repeatedly for local thread 01a014d1-afaf-79d1-8866-01a9ca6154e5.
After fully quitting and restarting the desktop app, a fresh archive request failed again at 2026-08-21T15:56:57Z.

Backend response:

errorCode=-32603
failed to archive session: thread-store internal error:
failed to archive thread: 系统找不到指定的文件。 (os error 2)

Immediately after the post-restart failure:

The thread remains in the active list with notLoaded.
It is absent from the archived list.
The database row remains archived = 0 and archived_at = NULL.

Read-only checks:

state_5.sqlite returns PRAGMA integrity_check = ok.
The affected rollout JSONL exists and is non-empty.
Its stored path uses the Windows extended prefix \\?\\C:\\..., while the corresponding workspace directory also exists.
No database edit, manual file move, app reset, or data deletion was performed.

Across the local logs I found 18 failures involving 5 distinct threads, while 17 other distinct threads had historical archive successes. The post-restart failure on the newer 26.818 package supports the extended-path/thread-store hypothesis, but I have not modified the path to test the workaround.

Hopefully fixed in CLI version >= 0.149 / GUI version >= 26.818.3698.

This is still reproducible on a Windows GUI build newer than the version mentioned as fixed above.

Environment:

Codex Desktop MSIX: 26.818.8289.0
Bundled codex-cli: 0.149.0-alpha.4.3
Windows x64, local Codex task
Restarting Codex and fully rebooting Windows did not help

Reproduction/result:

Archiving an existing local task from the Desktop UI does not move it to Archived Conversations.
Calling the built-in archive action directly hangs for more than 90 seconds.
The task remains in the active list with status notLoaded, is absent from the archived list, and its database row remains archived = 0 / archived_at = NULL.
The referenced rollout JSONL still exists, is readable, and its stored path is a normal absolute Windows path (no \\?\ prefix).
Because deletion is only offered for archived tasks, the task cannot be deleted either.

Sanitized log boundary for the failed attempt:

dynamic_app_tool_server_request_received ... tool=set_thread_archived
dynamic_app_tool_renderer_execution_started ... tool=set_thread_archived
response_routed ... method=thread/read errorCode=null
Archive requested ... source=dynamic_tool
codex-home request hostId=local

There is no subsequent thread/archive, thread/archived, or error in the log, and the state does not change. For comparison, a successful archive on the same machine in an earlier build logged codex-home request followed immediately by a successful thread/archive response.

So this reproduction appears to stall before thread/archive is dispatched, rather than failing later with os error 2. Since the GUI build is newer than 26.818.3698, could this issue be reopened or linked to the active tracking issue/fixed build?

Navigation Menu

Repository navigation

Could not archive conversation #39161

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Environment

Affected threads

Backend response

Read/archive state mismatch

Important filesystem check

Symptom

Root cause

Reproduction

Temporary workaround

Suggested product fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Could not archive conversation #39161

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 18, 2026

xiaodeng2025 commented on Aug 18, 2026

cmeeren commented on Aug 18, 2026

xiaodeng2025 commented on Aug 19, 2026

Environment

Affected threads

Backend response

Read/archive state mismatch

Important filesystem check

weijunswj commented on Aug 19, 2026

Symptom

Root cause

Reproduction

Temporary workaround

Suggested product fix

jonathanfisher commented on Aug 19, 2026

RaenonX commented on Aug 20, 2026

julesmhad commented on Aug 20, 2026

RaenonX commented on Aug 20, 2026

naipi11 commented on Aug 21, 2026

brettw-openai commented on Aug 23, 2026

morzmorz1996 commented on Aug 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions