Could not archive conversation

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

• #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:

``text
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:

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

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

Reproduction

1. Create and run a local Codex task on Windows.
2. Wait for the task to complete.
3. Inspect its threads.rollout_path in %USERPROFILE%\.codex\state_5.sqlite.
4. If the value begins with \\?\, try archiving the task.
5. Archiving fails with os error 2, although the rollout file exists.
6. Back up the database and remove only the \\?\ prefix from that row.
7. Retry archiving: it succeeds.
8. 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:

1. Normalize rollout_path before persisting it or before archive/unarchive filesystem operations.
2. Ensure the source and destination paths use compatible representations before moving the rollout file.
3. Avoid overwriting a normalized database value with a stale extended-path value held in memory.
4. Add a startup migration for existing affected threads.rollout_path rows, after confirming the corresponding file exists.
5. 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.

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:

1. Archiving an existing local task from the Desktop UI does not move it to Archived Conversations.
2. Calling the built-in archive action directly hangs for more than 90 seconds.
3. 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.
4. The referenced rollout JSONL still exists, is readable, and its stored path is a normal absolute Windows path (no \\?\ prefix).
5. 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?