Codex Desktop Windows: existing local session becomes unresolvable ("thread not found" / os error 2)

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

26.814.41407

What subscription do you have?

plus

What platform is your computer?

OS: Windows 11, build 10.0.26100

What issue are you seeing?

I can reproduce what appears to be a closely related issue on Codex Desktop for Windows, but in my case the failure affects both thread continuation and archiving.

Environment

• Codex Desktop: 26.814.41407
• Bundled CLI/app-server recorded in the session: 0.148.0-alpha.9
• OS: Windows 11, build 10.0.26100
• Host: local

Additional behavior

The affected thread remains visible in the Codex sidebar and its existing conversation can still be opened and read.

However, sending any new message fails with:

thread not found: <thread-id>

Attempting to archive the same thread also fails.

Calling the archive operation directly with the correct thread ID and hostId: local produces:

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

Local investigation

The underlying rollout JSONL file still exists under:

C:\Users\<username>\.codex\sessions\2026\08\18\
rollout-2026-08-18T11-20-18-<thread-id>.jsonl

I verified that:

• The file exists and is readable.
• The file is approximately 3.26 MB.
• session_meta.session_id matches the affected thread ID.
• The metadata timestamp matches the rollout filename.
• The thread is still present in the local thread catalog.
• Its host is local.
• Its status is notLoaded.
• The existing conversation can still be read through the thread-reading interface.

So in this case the rollout/session data itself does not appear to be missing or corrupted.

Workaround

I backed up the JSONL file, verified the backup with SHA-256, and manually moved the original rollout file from the dated sessions directory into:

C:\Users\<username>\.codex\archived_sessions

After doing this, the broken thread disappeared from the normal thread list.

Possible relation to this issue

This may be related to the Windows path normalization problem described here, although I have not confirmed whether the affected catalog entry specifically contains a \\?\-prefixed path.

One additional symptom in my case is that the thread-store cannot resolve the thread for continuation/resume, not only for archive, despite the rollout file still being present and readable.

It may be useful for the archive/resume path resolution logic to reconcile the stored catalog path against existing rollout files when the referenced path cannot be resolved.

I can provide the affected thread ID, screenshots, logs, and additional diagnostics privately if useful.

Best regards,
Huaiyu Yin

What steps can reproduce the bug?

I have not yet identified the exact action that initially causes the thread catalog/session path to become inconsistent. However, once the affected thread enters this state, the failure is consistently reproducible.

Steps to reproduce the observed failure

1. Open Codex Desktop on Windows.

2. Select the affected existing thread from the sidebar.

3. The existing conversation content is still displayed normally and can be read.

4. Send any new message in the thread.

5. Codex fails with:

   thread not found: <thread-id>

6. Try to archive the same thread from the Codex Desktop UI.

7. The archive operation also fails with a thread not found error.

8. Restart Codex Desktop and repeat steps 2–7.

   The problem persists after restart.

9. Calling the archive operation directly using the same thread ID with hostId: local fails with:

What is the expected behavior?

No response

Additional information

No response

Start with the local thread catalog, thread-reading interface, and archive/resume paths, using the affected rollout JSONL under .codex\sessions and archived_sessions as the concrete case. Check how the stored catalog path is resolved on Windows when the rollout file still exists and is readable. Done means an existing local thread can be continued and archived without thread-not-found or os error 2 failures.