Codex Desktop: archived local thread cannot be resumed after restore due to mismatched path between sessions/ and archived_sessions/

[davyleee]

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

26.422.71525

What subscription do you have?

Enterprise

What platform is your computer?

macOS 26.4.1 arm64

What issue are you seeing?

A local Codex Desktop thread became unrecoverable after being archived and then restored / reopened.

The UI repeatedly shows this error:

cannot resume running thread 019ddc40-fd28-7ca3-b05a-5de11ca24124 with mismatched path:
requested `/Users/sprite/.codex/sessions/2026/04/30/rollout-2026-04-30T10-38-59-019ddc40-fd28-7ca3-b05a-5de11ca24124.jsonl`,
active `/Users/sprite/.codex/archived_sessions/rollout-2026-04-30T10-38-59-019ddc40-fd28-7ca3-b05a-5de11ca24124.jsonl`

Important detail:
local state is already back to the non-archived path, but thread/resume still believes the active rollout lives under archived_sessions/.

Environment:
Codex Desktop App version: 26.422.71525
Bundled session metadata cli_version: 0.126.0-alpha.8
Platform: macOS 26.4.1 arm64
Additional evidence:

The session file now exists only under ~/.codex/sessions/...
The row in ~/.codex/state_5.sqlite is already archived=0 and points to sessions/...
Restarting Codex does not fix the mismatch
thread/read appears to succeed, but thread/resume fails immediately with JSON-RPC error -32600
This looks like a desktop archive/restore state mismatch between the indexed thread path and a separate active rollout path used by resume.

What steps can reproduce the bug?

I do not yet have a fully minimal repro, but this is the sequence that produced the issue:

1. Create and use a normal local desktop thread.
2. Archive that thread from the Codex Desktop UI.
3. Later try to restore / reopen / resume the archived thread from the UI.
4. Codex shows a restore failure dialog with a `mismatched path` error.
5. Fully quit and relaunch Codex.
6. Retry opening the same thread.
7. The same resume failure still occurs.

Observed local state after the failure:

1. The session JSONL exists only at:
   `~/.codex/sessions/2026/04/30/rollout-2026-04-30T10-38-59-019ddc40-fd28-7ca3-b05a-5de11ca24124.jsonl`
2. There is no matching session JSONL left under:
   `~/.codex/archived_sessions/`
3. The row in `~/.codex/state_5.sqlite` for thread `019ddc40-fd28-7ca3-b05a-5de11ca24124` is already non-archived and points to `sessions/...`
4. Despite that, the desktop app still reports that the active rollout path is `archived_sessions/...`

Thread id:
`019ddc40-fd28-7ca3-b05a-5de11ca24124`

### What is the expected behavior?

_No response_

### Additional information

_No response_

[github-actions]

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

• Archived local sessions hidden and fail to resume after switching auth/provider #19362

Powered by Codex Action

[scottbarbag-ux]

I’m seeing the same mismatched path resume failure text on Windows, but triggered through automation target threads rather than manual archive/restore.

In my case the immediate context is several heartbeat automations with persisted target_thread_id values. After using target-thread heartbeats as a workaround for the cron/new-thread automation dispatch bug (#19011), Desktop now sometimes fails before the automation starts with:

Failed to resume chat — cannot resume running thread with mismatched path

or times out waiting for thread/resume.

So this may be a broader Desktop resume-state issue: if a thread id is linked from another feature such as automation heartbeat, and Desktop has stale or conflicting rollout-path state for that thread, the feature that depends on thread/resume can fail before doing any useful work.

Not claiming this is an exact duplicate, because your repro is archive/restore-specific. The connection is that an old target_thread_id in an automation can hit the same resume path and expose the same kind of path mismatch.