›_ Codex Issues
Codex Issues / #20317

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

Resolved 💬 5 comments Opened Apr 30, 2026 by davyleee Closed Jun 7, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 4 months ago

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

  • #19362

Powered by Codex Action

scottbarbag-ux · 3 months ago

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.

davyleee · 3 months ago

Not a duplicate of #19362 — different root cause

The bot flagged #19362 as a potential duplicate, but the underlying bugs are distinct.

#19362 involves a state where SQLite correctly reflects archived=1 and rollout_path points to archived_sessions/, with the file still present there. The problem is that Codex provides no graceful way to resume a legitimately-archived session. It was triggered by an auth/provider switch.

This issue (#20317) is different. By the time thread/resume fails, the local state is already fully restored:

  • No file exists under archived_sessions/
  • The rollout JSONL is at sessions/2026/04/30/rollout-…-<id>.jsonl
  • The SQLite row has archived=0 and rollout_path pointing to sessions/…

Yet the error is:

cannot resume running thread with mismatched path:
requested `sessions/…`,
active `archived_sessions/…`

This means the Desktop process is holding a stale in-memory rollout path that was set before (or during) the archive→restore operation, and thread/resume uses that stale value instead of reading the current path from SQLite. The stale state survives a full app restart, which suggests it is persisted somewhere outside of SQLite and the filesystem — possibly in the app-server process state or a separate runtime cache.

Why the #19362 workaround does not apply here:
The recovery script in #19362 repairs SQLite rows that are still archived=1. In this case, SQLite is already correct. The issue is that the Desktop's resume path is not re-derived from SQLite after an archive→restore cycle.

In short:

  • #19362 = data is correctly archived, no recovery path exists
  • #20317 = data is already recovered in SQLite + filesystem, but Desktop's runtime resume path was never updated to match
alibrohde · 3 months ago

I’m seeing the same archive/session path mismatch on macOS, Codex Desktop 0.133.0-alpha.1.

Toast:

Failed to resume chat: cannot resume running thread 019e6970-fab9-75d2-98b3-9c801c327df4 with stale path: requested `/Users/alirohde/.codex/sessions/2026/05/27/rollout-2026-05-27T08-37-52-019e6970-fab9-75d2-98b3-9c801c327df4.jsonl`, active `/Users/alirohde/.codex/archived_sessions/rollout-2026-05-27T08-37-52-019e6970-fab9-75d2-98b3-9c801c327df4.jsonl`

Local state after failure:

  • The requested sessions/...jsonl path does not exist.
  • The archived_sessions/...jsonl file does exist.
  • state_5.sqlite has no row for this thread id.
  • session_index.jsonl still contains the thread id and title, so the UI can still surface a non-resumable chat.

Environment:

  • macOS 15.6.1 arm64
  • Codex Desktop app.version observed in logs: 0.133.0-alpha.1
  • Thread title in session_index.jsonl: Research Salesforce agent stance

This looks like the same class of bug: Desktop resume/session indexing can get out of sync after archive/restore or archive-related movement, leaving a visible chat that cannot be resumed.

robkam · 2 months ago

On Windows, using the Codex extension in VSCodium with WSL, archived chats end up under ~/.codex/archived_sessions.

Archive works, but I couldn’t find any unarchive option anywhere in the extension UI.

I first tried moving the rollout JSONL back into ~/.codex/sessions/YYYY/MM/DD/, but that alone did not restore the chat in Talk history. The chat only reappeared after I also updated the matching row in ~/.codex/state_*.sqlite to clear the archived state.

Environment:

  • Windows host
  • VSCodium
  • WSL backend
  • Codex extension
  • archived files in ~/.codex/archived_sessions
  • active session files in ~/.codex/sessions/YYYY/MM/DD/

It would help to expose an unarchive action in the extension, or document the full recovery path for this setup.