[Windows Desktop] thread/archive returns ENOENT for an existing local rollout

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

26.818.2441.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop cannot archive one specific local thread.

Codex App version: 26.818.2441.0
Thread ID: 01a01a8e-dab0-7bf0-a61f-5d330a89735f

Latest request ID:
4c8581e2-dc94-46b9-b2c1-3a526ea7d945

Previous request ID:
e4de4a14-1a88-4326-a955-8593029c0ab7

The App Server returns:

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

The rollout JSONL exists at its canonical path under:

%USERPROFILE%\.codex\sessions\2026\08\20\

The file contains 3696 parsed items with zero parse errors.

SHA-256:

F695A886E127672C3714D7C49D080DB6F4E999E7A175D4C01C12E1278FEFCF73

I verified the following:

• SQLite PRAGMA integrity_check returns ok.
• The thread row has archived=0 and archived_at=NULL.
• No file with the same name exists in archived_sessions.
• The rollout file is not read-only.
• ACLs are valid.
• No conflicting file handle or writer lock exists.
• The thread has no active external ownership.
• No partial archive update or data loss occurred.

The latest reproduction occurred while the target thread was unloaded.
There is no "thread was active; shutting down" entry for the latest request.

This appears to fail in the Windows LocalThreadStore filesystem move, possibly around path normalization or the rename from canonical_rollout_path to archived_path.

What steps can reproduce the bug?

1. Start Codex Desktop 26.818.2441.0 on Windows.
2. Confirm that thread 01a01a8e-dab0-7bf0-a61f-5d330a89735f is visible in the local sidebar.
3. Do not open or resume the target thread.
4. Right-click the thread in the sidebar.
5. Select Archive.
6. Observe the "Failed to archive chat" notification.
7. Check the Desktop log.

The thread/archive request returns JSON-RPC error -32603:

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

I also performed Windows App Repair, fully restarted Codex Desktop, left the target thread unloaded, and attempted the sidebar archive once. The same error occurred.

Latest reproduction request ID:
4c8581e2-dc94-46b9-b2c1-3a526ea7d945

What is the expected behavior?

Codex Desktop should move the existing rollout JSONL from the active sessions directory to archived_sessions, update the thread metadata to archived=1 with a non-null archived_at value, and show the thread in the Archived chats list.

The archive operation should succeed for a valid, readable, unloaded local thread without modifying or losing the rollout contents.

Additional information

The issue was reproduced after using Windows App Repair and fully restarting Codex Desktop.

For the latest reproduction, the target thread was not opened or resumed before selecting Archive from the sidebar. App Server logs contain no "thread was active; shutting down" entry for the latest request, which rules out the active-thread shutdown path.

Current storage state after the failure:

• The original rollout remains in the active sessions directory.
• No matching rollout exists in archived_sessions.
• SQLite still reports archived=0 and archived_at=NULL.
• PRAGMA integrity_check returns ok.
• No partial update or data loss occurred.
• No writer lock or conflicting file handle exists.
• The source and destination directories are on the same NTFS volume.

The source rollout is readable and was successfully parsed as 3696 items with zero parse errors.

The failure returns in approximately 87 ms, so it does not appear to be a timeout.

Please inspect the resolved source and destination paths immediately before:

std::fs::rename(canonical_rollout_path, archived_path)

In particular, please check Windows path normalization, the \\?\ long-path representation, and try_exists() results for both paths immediately before the rename operation.

I have not manually moved the rollout or modified the SQLite database.