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

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

• #39150
• #39130

Powered by Codex Action

Additional reproduction (Windows local session):

• Codex Desktop: 26.814.41407
• Bundled CLI/app-server: 0.148.0-alpha.9
• Host: local

1. Archive a local session successfully.
2. Unarchive it from Settings > Archived chats.
3. Archive the same session again.
4. The second archive fails with:

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

The existing transcript remains readable. A local diagnostic check shows that unarchive/reindexing rewrites the catalog entry using an extended-length Windows path form; normalizing that path form makes the archive operation succeed. This suggests a Windows path-normalization or catalog-path reconciliation regression specifically after unarchiving a local session.

I can reproduce this on Codex Desktop for Windows.

Environment:

• Codex Desktop: 26.814.5167.0
• OS: Windows 11
• Host: local

Affected thread IDs:

• 01a017be-c82f-7d42-87ee-172db8679aa6
• 01a01362-1019-7133-b701-3fe7715e62cb

Both threads remain visible in the Recent sidebar, but cannot be resumed or archived.

The UI shows:

failed to resolve rollout path
\\?\C:\Users\<username>\.codex\sessions\2026\08\19\
rollout-2026-08-19T09-59-34-01a017be-c82f-7d42-87ee-172db8679aa6.jsonl:
file does not exist

Archiving also fails with:

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 is already missing, but the local thread catalog/sidebar metadata continues to reference it after restarting Codex. This leaves an undeletable, unarchivable orphan entry in the UI.

Expected behavior:

• Automatically remove or repair catalog entries whose rollout path no longer exists.
• Provide a “Forget/Delete broken local session” action that does not require opening or archiving the missing rollout file.

Additional independent reproduction on Codex Desktop for Windows (2026-08-20).

Environment:

• Windows 11 Pro, build 26200, x64
• Codex MSIX package: 26.814.5517.0
• Session metadata recorded app-server/CLI: 0.148.0-alpha.15
• Local thread associated with a ChatGPT-origin local project

Observed behavior:

• The affected thread remained visible and its existing conversation could be opened/read.
• Sending a follow-up failed with thread not found: <thread-id>.
• Archiving from the sidebar and through the native task-management action failed consistently with JSON-RPC -32603:

failed to archive session: thread-store internal error: failed to archive thread: Den angivne fil blev ikke fundet. (os error 2)

• Restarting Codex did not resolve it.
• The rollout JSONL existed, was readable, and its session_meta.session_id matched the thread.
• A scan of local Desktop logs found seven archive failures, all for this single thread; no other local thread had this error.

Notable recovery observation:

• The rollout filename used local wall-clock time (11-23-43) while session_meta.timestamp was 09:23:43Z.
• After backing up the rollout and temporarily providing an identical filename using the timestamp-derived UTC form (09-23-43), the native thread/archive operation succeeded.
• The thread then disappeared from the active list, appeared in the archived list, and the SQLite row was updated to archived=1.
• This observation may be related to path resolution/index reconciliation; I have not established whether the prior SQLite path used a Windows verbatim \\?\ prefix.

No conversation content, user paths, or raw logs are included.

Additional reproduction on Codex Desktop for Windows.

Environment

• Codex Desktop package: 26.818.2441.0 (x64)
• Bundled CLI recorded in the affected session: 0.148.0-alpha.15
• Host: local Windows
• Time zone: Europe/London (BST, UTC+1 at the time)
• Affected task: Review FX EA test handoff
• Thread ID: 01a016c0-d177-7a32-b138-15192bfecfed

Important sequence of events

1. The completed chat was visible in the sidebar but would not archive through the normal UI. This archive failure happened first, before any manual movement or deletion of local files.
2. A new prompt was then sent to that same visible chat.
3. At 11:49 local time, Codex returned:

``text
thread not found: 01a016c0-d177-7a32-b138-15192bfecfed
``

1. A direct archive attempt using the same thread ID then returned:

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

1. Restarting Codex did not make the sidebar archive action work.

Local evidence before deletion

The rollout file still existed and was readable at the time the native archive operation failed. Its filename timestamp was:

rollout-2026-08-18T22-22-10-<thread-id>.jsonl

The first session_meta record contained:

2026-08-18T21:22:10.530Z

The filename was therefore exactly one hour ahead of the UTC metadata timestamp, matching British Summer Time. This appears consistent with the UTC/local-time filename mismatch reported in #39575, but here the observable failure also progressed to thread not found when a new prompt was sent.

The session file was manually deleted only after all of the above failures while trying to remove the unusable sidebar entry. That deletion was a later troubleshooting action and did not cause the original archive or continuation failures.

Expected behavior

A visible completed task should archive normally. If its rollout path cannot be resolved, Codex should reconcile the thread ID against the existing rollout file rather than leaving a sidebar task that cannot be archived or continued.

A controlled four-thread comparison provides additional evidence that this failure is specific to cold/not-loaded thread resume, rather than missing conversation data or deletion of the originating schedule.

Environment

• Codex Desktop package: 26.818.2441.0 (Windows x64)
• Original bundled CLI recorded in these sessions: 0.147.0-alpha.6.6
• Time zone when created: Europe/London (BST, UTC+1)
• All four were sibling subagent threads created within six seconds for a scheduled model-comparison test.
• The schedule definitions have since been deleted, but all four rollout files still exist and are readable.

Results

| Variant | Thread ID | Current status | New prompt result |
| --- | --- | --- | --- |
| GPT-5.5 light | 01a0017c-0500-79e2-86cd-ca460f69b1a8 | notLoaded | thread not found |
| Sol light | 01a0017b-fde4-7cd2-959c-ee5a08d5d8a9 | idle | Succeeds |
| Terra light | 01a0017b-f6d0-7ea3-b81a-050ec4ad9962 | idle | Succeeds |
| Luna light | 01a0017b-ef92-71d3-8adb-8f67e2390fd4 | notLoaded | thread not found |

Exact errors for the two failing tasks:

thread not found: 01a0017c-0500-79e2-86cd-ca460f69b1a8
thread not found: 01a0017b-ef92-71d3-8adb-8f67e2390fd4

The thread-reading interface can still read the complete original turns from both failing threads, confirming that the rollout contents remain available. The failure occurs when trying to continue/resume them.

Cold versus refreshed state

The two working sessions (Sol and Terra) successfully accepted a test turn on 20 August. Their rollout files grew from the original run and their states are now idle.

The two failing sessions (GPT-5.5 and Luna) contain only their original short runs from 14 August and remain notLoaded.

This makes the key boundary reproducible within an otherwise matched four-thread group:

• already refreshed/loaded thread -> continuation works;
• old notLoaded thread -> continuation returns thread not found.

BST/UTC filename mismatch across all four

Each rollout filename uses local BST while its session_meta.timestamp uses UTC, with an exact one-hour difference. Examples:

GPT-5.5 filename: 2026-08-14T19-15-00
GPT-5.5 metadata: 2026-08-14T18:15:00.127Z

Luna filename:    2026-08-14T19-14-54
Luna metadata:    2026-08-14T18:14:54.643Z

All four database rollout_path values point to existing files. The paths also use the Windows verbatim \\?\C:\... form.

This appears consistent with #39575: a loaded thread may retain/use its resolved actual path, while a cold notLoaded resume may reconstruct or normalize the filename/path and fail because of the UTC/local-time mismatch (possibly compounded by the \\?\ prefix).

Deleting the schedule definitions did not delete these rollout files and does not explain why two sibling tasks work while two fail.

Separate title-encoding symptom

All four sidebar/read-interface titles render an intended em dash as mojibake:

Budget app test — Luna light
Budget app test — Terra light
Budget app test — Sol light
Budget app test — GPT-5.5 light

This appears to be a separate title-generation or decoding defect; it affects both working and failing threads.

Expected behavior

A readable notLoaded thread with an existing rollout file should resume exactly as an already-loaded sibling thread does. Schedule deletion should not leave retained run tasks that are readable but cannot be continued or archived. If completed automation/subagent runs are intentionally retained, they should remain manageable through the normal archive operation.

Additional Windows reproduction with a confirmed local root-cause/workaround. This affects more than archive→unarchive→archive: some pre-existing local tasks can fail to archive even without a prior unarchive, and an affected task can also become temporarily unable to continue.

Observed behavior:

• Existing local task remains visible/readable in Codex Desktop.
• Archive fails from the normal UI.
• Sending a new message to the same affected task can fail with:

thread not found: <thread-id>

• Fully restarting Codex Desktop makes the task readable/continuable again, but does not reliably fix the archive failure.
• Newly created comparison threads can archive normally.

Local state evidence on one affected thread:

• state_5.sqlite.threads.archived = 0
• archived_at = NULL
• rollout JSONL exists and is readable under sessions
• no duplicate JSONL and no matching file in archived_sessions
• SQLite/file location/thread id are mutually consistent
• PRAGMA integrity_check returns ok
• affected threads.rollout_path used the Windows verbatim/extended form:

\\?\C:\Users\<user>\.codex\sessions\...\rollout-<thread-id>.jsonl

• a healthy new thread in the same project used the ordinary form:

C:\Users\<user>\.codex\sessions\...

Controlled repair:

1. Backed up Codex local state first.
2. Changed only the affected row's rollout_path, normalizing the verbatim \\?\C:\... form to the ordinary C:\... form.
3. Did not manually change archived/archived_at and did not move/delete the rollout JSONL.
4. Invoked the real Codex thread/archive path.

Result:

• Archive immediately succeeded.
• The same target then passed a real archive → unarchive → archive round trip.
• A new post-fix temporary thread also passed archive → unarchive → archive.
• No thread not found occurred in the post-fix round trip.
• The target rollout JSONL SHA-256 was unchanged.
• Existing project/thread registration state remained intact.

This suggests the Windows verbatim-path representation is not only related to archive os error 2, but can also contribute to a thread becoming unresolvable for continuation in Desktop/app-server state. The failure is not limited to threads that were previously archived/unarchived; older/pre-existing tasks can already carry the problematic path form.

This appears closely related to #39150, #39209 and #39239. A durable fix likely needs consistent Windows path normalization/canonical identity across list/resume persistence and archive resolution, rather than relying on users to rewrite state_5.sqlite manually.

No conversation contents, raw state databases, usernames, local project names, or real thread IDs are included here.

this is happening all the time to me

Independent, non-destructive recovery observation for one thread not found case. I am not claiming that this has the same root cause as every os error 2 / rollout-path failure reported here.

Preconditions observed

• The affected local task was still readable through the task-reading interface.
• Its latest turn had been interrupted.
• A normal follow-up from the affected task's own UI had failed with thread not found.
• No local database, rollout JSONL, or app cache was edited.
• An unarchive attempt returned no archived rollout found, so unarchiving was not the recovery action.

Recovery probe that succeeded

From a separate healthy Codex task, I asked Codex to use its task-management tools against the exact affected task ID on host local:

1. Call read_thread for the affected ID.
2. Only if the task is readable, call send_message_to_thread with this minimal prompt:

``text
Connection recovery test: do not read files, call tools, or continue old work. Only reply: "Thread recovered; conversation is working."
``

1. Call wait_threads and require a completed turn with no error and the expected reply.
2. Navigate back to the affected task.

The probe turn completed successfully. More importantly, the task subsequently completed a normal substantive user turn, confirming that continuation really was restored. No session files or SQLite rows were changed.

Important correction and limits

notLoaded by itself is not a reliable failure/recovery criterion: after successful use, the task can later be unloaded and show notLoaded again. The meaningful checks are whether a new turn completes without error and whether subsequent normal conversation works.

This is a reproducible, low-risk probe only for the case where read_thread can still read the task. If reading or cross-task sending fails, the rollout is missing, or os error 2 persists, stop; that is likely a different path/catalog failure and this observation should not be treated as a fix for it.

A user-facing prompt for another healthy Codex task is:

Use Codex task-management tools only. For task <THREAD_ID> on host local:
1) read it;
2) if readable, send a no-tools recovery probe;
3) wait for completion;
4) if it completes without error, navigate to it.
Do not edit SQLite, move rollout files, or clear local state. Stop and report if any operation returns not found or os error 2.