Windows 11: Codex Desktop 26.513.31313 shows “Oops, an error has occurred” when resuming existing thread

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

• #22981
• #22969
• #22971
• #22854
• #21659

Powered by Codex Action

@simon-ami

Hi, I fixed the issue locally and created another issue thread for reference. You can send this solution to your Codex app.

https://github.com/openai/codex/issues/22985

@simon-ami Hi, I fixed the issue locally and created another issue thread for reference. You can send this solution to your Codex app. #22985

Thanks, I see the analysis in #22985, but I don’t see an actual patch, script, or exact repair command there.

Could you share the specific script/commands you used, or a minimal before/after example of one affected JSONL entry?

I’d also prefer to avoid bulk-editing %USERPROFILE%\.codex\sessions without a backup and without maintainer confirmation, since an overly broad replacement could corrupt local history.

> @simon-ami > Hi, I fixed the issue locally and created another issue thread for reference. You can send this solution to your Codex app. > #22985 Thanks, I see the analysis in #22985, but I don’t see an actual patch, script, or exact repair command there. Could you share the specific script/commands you used, or a minimal before/after example of one affected JSONL entry? I’d also prefer to avoid bulk-editing %USERPROFILE%\.codex\sessions without a backup and without maintainer confirmation, since an overly broad replacement could corrupt local history.

Here is my fix. Unfortunately, this parsing error requires modifying %USERPROFILE%\.codex\sessions, so we should back it up first.
Hope this helps, or at least gives you a starting point.

Fix Codex Desktop history threads failing to open on Windows.

Goal: only repair Codex directive paths inside JSONL files under `%USERPROFILE%\.codex\sessions` and `%USERPROFILE%\.codex\archived_sessions`. Do not delete conversations, do not slim/truncate history, and do not modify any project repo.

Known root cause: old messages may contain directive attributes with Windows backslash paths, which can crash the Codex Desktop renderer/parser. Only convert Windows absolute path separators inside directive attributes named `cwd`, `cwds`, or `file` from backslash to slash.

Process:
1. First count `sessions`, `archived_sessions`, and `session_index.jsonl` to confirm the data is still present.
2. Scan JSONL files, but only process `cwd` / `cwds` / `file` attributes inside directive-shaped text.
3. Before writing, back up every file to `.codex\session_repair_backups\<timestamp>-directive-path-fix` and write a manifest.
4. Only change Windows path separators inside directive attributes. Do not change normal chat text.
5. After repair, parse every modified JSONL file line by line, and rescan to confirm the remaining offending directive path count is 0.
6. Use `thread/read` to spot-check a few previously broken threads.
7. Report how many files were changed, how many path attributes were repaired, the backup location, and the validation results.

Important: do not include any complete raw directive plus Windows backslash path example in the final answer, or this repair thread may break itself again.

Update: confirmed workaround for my affected session.

Codex Desktop 26.513.31313 on Windows 11 was consistently failing to resume one specific session (from my sparse testing):

019e276d-6c96-74b0-8349-110889972d3c

The session file itself was valid JSONL:

total lines: 1891
bad lines: 0
````

The app-server logs showed `thread/resume` reaching the backend for that session, but no JSONL parse error, panic, or backend `ERROR`. The recurring PowerShell warning:

```text
Failed to create shell snapshot for powershell:
Shell snapshot not supported yet for PowerShell

also appeared for other sessions that resumed successfully, so that does not seem to be the direct cause.

The failing session contained directive-shaped assistant output with Windows backslash paths in directive cwd attributes, matching the pattern described in #22985. A narrow one-file repair changed only those directive cwd paths from backslashes to forward slashes. It changed 21 directive cwd paths. After re-validating the JSONL and fully restarting Codex Desktop, the previously broken session resumes successfully.

So this looks like a Desktop history renderer/parser issue triggered by directive-shaped text containing Windows cwd paths, rather than general session corruption.

> > @simon-ami > > Hi, I fixed the issue locally and created another issue thread for reference. You can send this solution to your Codex app. > > #22985 > > > Thanks, I see the analysis in #22985, but I don’t see an actual patch, script, or exact repair command there. > Could you share the specific script/commands you used, or a minimal before/after example of one affected JSONL entry? > I’d also prefer to avoid bulk-editing %USERPROFILE%\.codex\sessions without a backup and without maintainer confirmation, since an overly broad replacement could corrupt local history. Here is my fix. Unfortunately, this parsing error requires modifying %USERPROFILE%.codex\sessions, so we should back it up first. Hope this helps, or at least gives you a starting point. `` Fix Codex Desktop history threads failing to open on Windows. Goal: only repair Codex directive paths inside JSONL files under %USERPROFILE%\.codex\sessions and %USERPROFILE%\.codex\archived_sessions. Do not delete conversations, do not slim/truncate history, and do not modify any project repo. Known root cause: old messages may contain directive attributes with Windows backslash paths, which can crash the Codex Desktop renderer/parser. Only convert Windows absolute path separators inside directive attributes named cwd, cwds, or file from backslash to slash. Process: 1. First count sessions, archived_sessions, and session_index.jsonl to confirm the data is still present. 2. Scan JSONL files, but only process cwd / cwds / file attributes inside directive-shaped text. 3. Before writing, back up every file to .codex\session_repair_backups\<timestamp>-directive-path-fix and write a manifest. 4. Only change Windows path separators inside directive attributes. Do not change normal chat text. 5. After repair, parse every modified JSONL file line by line, and rescan to confirm the remaining offending directive path count is 0. 6. Use thread/read to spot-check a few previously broken threads. 7. Report how many files were changed, how many path attributes were repaired, the backup location, and the validation results. Important: do not include any complete raw directive plus Windows backslash path example in the final answer, or this repair thread may break itself again. ``

Thanks, confirmed. Your diagnosis was correct for my case.

I found 21 directive cwd attributes with Windows backslash paths in the failing session JSONL. After backing up the file, converting only those directive cwd paths to forward-slash paths, and validating the JSONL again, the thread resumes successfully after restarting Codex Desktop.

I have an additional data point from a local mitigation that consistently restored the broken pre-upgrade threads on my machine.

This was done with a sanitized local compatibility repair, not by recreating threads and not by recovering from backups.

Observed repair rule:

1. Read ~/.codex/session_index.jsonl to identify user-visible local thread IDs.
2. Scan ~/.codex/sessions/**/rollout-*.jsonl.
3. For each rollout:

• parse the first JSONL line
• if it is type == "session_meta"
• and payload.id is present in session_index.jsonl
• and payload.thread_source is missing or empty
• then backfill payload.thread_source = "user"

1. Restart Codex App.

Important safety constraint:

• do not blindly infer thread_source for every rollout on disk
• only repair indexed / user-visible top-level threads
• do not overwrite existing thread_source values such as subagent threads

Minimal sanitized Python version of the local repair logic:

import json
from pathlib import Path

codex_home = Path.home() / ".codex"
session_index = codex_home / "session_index.jsonl"
sessions_root = codex_home / "sessions"

indexed_ids = set()
for line in session_index.read_text(encoding="utf-8").splitlines():
    if not line.strip():
        continue
    try:
        indexed_ids.add(json.loads(line)["id"])
    except Exception:
        pass

for rollout in sessions_root.rglob("rollout-*.jsonl"):
    lines = rollout.read_text(encoding="utf-8").splitlines()
    if not lines:
        continue

    try:
        first = json.loads(lines[0])
    except Exception:
        continue

    payload = first.get("payload") or {}
    thread_id = payload.get("id")
    if thread_id not in indexed_ids:
        continue
    if payload.get("thread_source"):
        continue

    payload["thread_source"] = "user"
    lines[0] = json.dumps(first, ensure_ascii=False, separators=(",", ":"))
    rollout.write_text("\\n".join(lines) + "\\n", encoding="utf-8")

This local repair fully restored the old broken threads for me.

Additional verification from the repaired dataset:

• all indexed / user-visible rollout files became compatible
• newly created post-upgrade threads were already fine and were left unchanged
• non-indexed rollouts were intentionally not inferred / rewritten

I also wrote local tests for this repair rule before applying it, covering:

• indexed rollout with missing thread_source gets repaired
• rollout not present in session_index.jsonl is not modified
• rollout with an existing thread_source is preserved

This is obviously only a mitigation, not the correct product fix. But it strongly suggests the app should either:

• treat missing thread_source on older local rollout metadata as a backward-compatible user default when appropriate, or
• run a built-in one-time metadata migration for historical local rollouts.

I can confirm that this issue also occurs on my computer in Codex Desktop version 26.513.31313, as mentioned in this thread.

In my case, the bug makes the Codex Desktop app effectively unusable, so I would consider this a major regression that needs an urgent fix from OpenAI.

I also experienced the same problem with a newly created thread while the agent was actively working. The thread crashed and now shows the same “Oops, an error has occurred” message when I try to reopen it.

confirm, stumbled upon same bug on latest version of Codex Desktop on Windows 26.513.31313

> > > @simon-ami > > > Hi, I fixed the issue locally and created another issue thread for reference. You can send this solution to your Codex app. > > > #22985 > > > > > > Thanks, I see the analysis in #22985, but I don’t see an actual patch, script, or exact repair command there. > > Could you share the specific script/commands you used, or a minimal before/after example of one affected JSONL entry? > > I’d also prefer to avoid bulk-editing %USERPROFILE%\.codex\sessions without a backup and without maintainer confirmation, since an overly broad replacement could corrupt local history. > > > Here is my fix. Unfortunately, this parsing error requires modifying %USERPROFILE%.codex\sessions, so we should back it up first. Hope this helps, or at least gives you a starting point. > `` > Fix Codex Desktop history threads failing to open on Windows. > > Goal: only repair Codex directive paths inside JSONL files under %USERPROFILE%\.codex\sessions and %USERPROFILE%\.codex\archived_sessions. Do not delete conversations, do not slim/truncate history, and do not modify any project repo. > > Known root cause: old messages may contain directive attributes with Windows backslash paths, which can crash the Codex Desktop renderer/parser. Only convert Windows absolute path separators inside directive attributes named cwd, cwds, or file from backslash to slash. > > Process: > 1. First count sessions, archived_sessions, and session_index.jsonl to confirm the data is still present. > 2. Scan JSONL files, but only process cwd / cwds / file attributes inside directive-shaped text. > 3. Before writing, back up every file to .codex\session_repair_backups\<timestamp>-directive-path-fix and write a manifest. > 4. Only change Windows path separators inside directive attributes. Do not change normal chat text. > 5. After repair, parse every modified JSONL file line by line, and rescan to confirm the remaining offending directive path count is 0. > 6. Use thread/read to spot-check a few previously broken threads. > 7. Report how many files were changed, how many path attributes were repaired, the backup location, and the validation results. > > Important: do not include any complete raw directive plus Windows backslash path example in the final answer, or this repair thread may break itself again. > ` Thanks, confirmed. Your diagnosis was correct for my case. I found 21 directive cwd attributes with Windows backslash paths in the failing session JSONL. After backing up the file, converting only those directive cwd` paths to forward-slash paths, and validating the JSONL again, the thread resumes successfully after restarting Codex Desktop.

This worked for me too.

We're working on a hotfix for this. The update should be available in the Windows store shortly.

I have the same issue on Windows 11 after updating to 26.513.31313. Sessions crash after a while and become inaccessible.

We've issued a hotfix to address this. Please update to the latest version.