LocalConversationPage crashes when opening some existing chats

Open 💬 7 comments Opened May 16, 2026 by hastwrkasauasksauk7-ux

💡 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.513.3673.0

What subscription do you have?

pro

What platform is your computer?

Windows x64

What issue are you seeing?

Codex Desktop bug report: LocalConversationPage crashes when opening some existing chats

Summary

Some existing Codex Desktop conversations cannot be opened anymore. When clicking the affected chats, the UI shows a generic error page:

糟糕，出错了

New or unaffected conversations still work, but multiple historical conversations crash the local conversation page, making the app hard to use.

Environment

App: OpenAI Codex Desktop, Microsoft Store build
Codex App version: 26.513.3673.0
Package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
Platform: Windows x64
Workspace path pattern involved: Windows absolute paths, for example C:\Users\<user>\Desktop\D3-Code\delivery-java\delivery-rebuild-order-service
Local timezone: Asia/Shanghai

Reproduction Steps

Open Codex Desktop on Windows.
Open an existing historical conversation that contains previous work in a Windows workspace.
The conversation initially routes/resumes successfully.
The UI then crashes into the generic error boundary page: 糟糕，出错了.
Clicking retry does not reliably recover the affected conversation.

Actual Result

The local conversation page crashes while rendering a previously completed thread.

Expected Result

Codex Desktop should render the conversation history successfully. If one historical item cannot be parsed or rendered, the app should isolate that item and keep the conversation usable instead of crashing the whole page.

Key Local Log Evidence

Log file:

C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\16\codex-desktop-5665250b-2bd7-41b4-ae8b-8bfad293a06d-21412-t0-i1-050704-0.log

Observed around 2026-05-16 13:08 to 13:19 local time.

The thread resume itself succeeds, then the page crashes:

maybe_resume_success conversationId=019dadb2-4957-7dd0-b7d2-908445b3e30b latestTurnStatus=completed markedStreaming=true
error [electron-message-handler] error boundary ... name=LocalConversationPage
errorMessage="invalid syntax at line 1 col 5:

1  cwd=\"C:\\Users\\<user>\\Desktop\\D3-Code\\delivery-java\\delivery-rebuild-order-service\"
       ^"

The stack includes:

markdown-D32gobzN.js
local-conversation-thread-BKrlVhAv.js
review-file-source-tab-BmlwHNat.js
local-conversation-page-Vm2E5OJ5.js
LocalConversationPage

This repeats for multiple affected conversations, including:

019dadb2-4957-7dd0-b7d2-908445b3e30b
019d7002-1387-7ee3-8b15-5e7bebca7ac9
019dfe16-b386-7973-9d9f-d0d72e6740d8

There are also benign-looking thread/goal/get failures:

error={"code":-32600,"message":"goals feature is disabled"}

But the page crash happens after successful thread/resume / maybe_resume_success, and the fatal symptom is the LocalConversationPage error boundary with invalid syntax at line 1 col 5 while parsing a cwd="C:\..." line.

Local Data Integrity Check

The local thread database was checked separately:

C:\Users\<user>\.codex\state_5.sqlite
Total thread rollout paths checked: 107
Missing rollout paths: 0
Empty rollout paths: 0
Invalid sampled rollout files: 0

So this does not look like missing local conversation files. It looks like a frontend rendering/parsing crash for specific historical content.

Suspected Cause

The renderer appears to parse a Windows command/source/review snippet containing:

cwd="C:\Users\<user>\Desktop\D3-Code\delivery-java\delivery-rebuild-order-service"

as a syntax item, fails at column 5, and throws through review-file-source-tab / markdown rendering, crashing the full LocalConversationPage.

Impact

This makes multiple existing conversations unusable. The user cannot reliably reopen important historical threads, and normal app usage is blocked because clicking affected conversations crashes the page.

Request

Please fix the Codex Desktop renderer so invalid or unexpected historical source/review/markdown content is isolated instead of crashing the whole conversation page. A fallback rendering path for unparsable source snippets would unblock affected users.

What steps can reproduce the bug?

Codex Desktop bug report: LocalConversationPage crashes when opening some existing chats

Summary

Some existing Codex Desktop conversations cannot be opened anymore. When clicking the affected chats, the UI shows a generic error page:

糟糕，出错了

New or unaffected conversations still work, but multiple historical conversations crash the local conversation page, making the app hard to use.

Environment

App: OpenAI Codex Desktop, Microsoft Store build
Codex App version: 26.513.3673.0
Package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
Platform: Windows x64
Workspace path pattern involved: Windows absolute paths, for example C:\Users\<user>\Desktop\D3-Code\delivery-java\delivery-rebuild-order-service
Local timezone: Asia/Shanghai

Reproduction Steps

Open Codex Desktop on Windows.
Open an existing historical conversation that contains previous work in a Windows workspace.
The conversation initially routes/resumes successfully.
The UI then crashes into the generic error boundary page: 糟糕，出错了.
Clicking retry does not reliably recover the affected conversation.

Actual Result

The local conversation page crashes while rendering a previously completed thread.

Expected Result

Key Local Log Evidence

Log file:

C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\16\codex-desktop-5665250b-2bd7-41b4-ae8b-8bfad293a06d-21412-t0-i1-050704-0.log

Observed around 2026-05-16 13:08 to 13:19 local time.

The thread resume itself succeeds, then the page crashes:

maybe_resume_success conversationId=019dadb2-4957-7dd0-b7d2-908445b3e30b latestTurnStatus=completed markedStreaming=true
error [electron-message-handler] error boundary ... name=LocalConversationPage
errorMessage="invalid syntax at line 1 col 5:

1  cwd=\"C:\\Users\\<user>\\Desktop\\D3-Code\\delivery-java\\delivery-rebuild-order-service\"
       ^"

The stack includes:

markdown-D32gobzN.js
local-conversation-thread-BKrlVhAv.js
review-file-source-tab-BmlwHNat.js
local-conversation-page-Vm2E5OJ5.js
LocalConversationPage

This repeats for multiple affected conversations, including:

019dadb2-4957-7dd0-b7d2-908445b3e30b
019d7002-1387-7ee3-8b15-5e7bebca7ac9
019dfe16-b386-7973-9d9f-d0d72e6740d8

There are also benign-looking thread/goal/get failures:

error={"code":-32600,"message":"goals feature is disabled"}

Local Data Integrity Check

The local thread database was checked separately:

C:\Users\<user>\.codex\state_5.sqlite
Total thread rollout paths checked: 107
Missing rollout paths: 0
Empty rollout paths: 0
Invalid sampled rollout files: 0

So this does not look like missing local conversation files. It looks like a frontend rendering/parsing crash for specific historical content.

Suspected Cause

The renderer appears to parse a Windows command/source/review snippet containing:

cwd="C:\Users\<user>\Desktop\D3-Code\delivery-java\delivery-rebuild-order-service"

as a syntax item, fails at column 5, and throws through review-file-source-tab / markdown rendering, crashing the full LocalConversationPage.

Impact

Request

What is the expected behavior?

Codex Desktop bug report: LocalConversationPage crashes when opening some existing chats

Summary

Some existing Codex Desktop conversations cannot be opened anymore. When clicking the affected chats, the UI shows a generic error page:

糟糕，出错了

New or unaffected conversations still work, but multiple historical conversations crash the local conversation page, making the app hard to use.

Environment

App: OpenAI Codex Desktop, Microsoft Store build
Codex App version: 26.513.3673.0
Package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
Platform: Windows x64
Workspace path pattern involved: Windows absolute paths, for example C:\Users\<user>\Desktop\D3-Code\delivery-java\delivery-rebuild-order-service
Local timezone: Asia/Shanghai

Reproduction Steps

Open Codex Desktop on Windows.
Open an existing historical conversation that contains previous work in a Windows workspace.
The conversation initially routes/resumes successfully.
The UI then crashes into the generic error boundary page: 糟糕，出错了.
Clicking retry does not reliably recover the affected conversation.

Actual Result

The local conversation page crashes while rendering a previously completed thread.

Expected Result

Key Local Log Evidence

Log file:

C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\16\codex-desktop-5665250b-2bd7-41b4-ae8b-8bfad293a06d-21412-t0-i1-050704-0.log

Observed around 2026-05-16 13:08 to 13:19 local time.

The thread resume itself succeeds, then the page crashes:

maybe_resume_success conversationId=019dadb2-4957-7dd0-b7d2-908445b3e30b latestTurnStatus=completed markedStreaming=true
error [electron-message-handler] error boundary ... name=LocalConversationPage
errorMessage="invalid syntax at line 1 col 5:

1  cwd=\"C:\\Users\\<user>\\Desktop\\D3-Code\\delivery-java\\delivery-rebuild-order-service\"
       ^"

The stack includes:

markdown-D32gobzN.js
local-conversation-thread-BKrlVhAv.js
review-file-source-tab-BmlwHNat.js
local-conversation-page-Vm2E5OJ5.js
LocalConversationPage

This repeats for multiple affected conversations, including:

019dadb2-4957-7dd0-b7d2-908445b3e30b
019d7002-1387-7ee3-8b15-5e7bebca7ac9
019dfe16-b386-7973-9d9f-d0d72e6740d8

There are also benign-looking thread/goal/get failures:

error={"code":-32600,"message":"goals feature is disabled"}

Local Data Integrity Check

The local thread database was checked separately:

C:\Users\<user>\.codex\state_5.sqlite
Total thread rollout paths checked: 107
Missing rollout paths: 0
Empty rollout paths: 0
Invalid sampled rollout files: 0

So this does not look like missing local conversation files. It looks like a frontend rendering/parsing crash for specific historical content.

Suspected Cause

The renderer appears to parse a Windows command/source/review snippet containing:

cwd="C:\Users\<user>\Desktop\D3-Code\delivery-java\delivery-rebuild-order-service"

as a syntax item, fails at column 5, and throws through review-file-source-tab / markdown rendering, crashing the full LocalConversationPage.

Impact

Request

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 3 months ago

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

#22956
#22961

Powered by Codex Action

Stef9332 · 3 months ago

I can reproduce the same issue on Windows after the latest Codex Desktop update.

Visible symptom:

Opening older local chats shows the generic “Oops, an error has occurred” page.
“Check again for updates” reports no newer update.
Retry does not recover the affected thread.

Local log evidence:

thread/resume succeeds / maybe_resume_success appears.
Then the renderer fails with:

Error: invalid syntax at line 1 col 5

The offending parsed text starts with:

cwd="C:\Users\<user>\Documents\..."

There are also thread/goal/get errors with:
goals feature is disabled
but those appear non-fatal. The fatal symptom is the renderer/parser crash on the Windows cwd path while opening historical conversations.

This started after updating Codex Desktop on Windows on 2026-05-16.

TriS1x · 3 months ago

I encountered the same issue and was able to temporarily resolve it by opening a new Codex conversation, using it to troubleshoot the affected sessions, applying a local fix, and then restarting Codex Desktop.

However, the issue may recur if a later conversation triggers Git-related commands again. Below is my current understanding of the problem and workaround, in case it helps others.

Symptoms

When opening certain historical conversations in Codex Desktop, the session page crashes and enters an error boundary. The UI may show messages such as:

Oops, an errors has occurred
Check for updates
Try again

In my case, the affected sessions were not actually corrupted.

Root Cause

This does not appear to be a project code issue, nor does it seem to be caused by a corrupted session index.

The likely root cause is that Codex Desktop's frontend fails while rendering Markdown from historical session messages.

More specifically, some historical messages contained Codex Git inline directives with Windows-style paths, for example directives that included a cwd parameter like:

C:\Users\...\project

The current Codex Desktop renderer appears to throw a syntax error when parsing certain Windows backslash paths inside these Git inline directives. As a result, the entire session page crashes during frontend rendering.

Investigation Process

The logs showed that both thread/read and thread/resume completed successfully for the affected sessions. This suggests that the backend was able to read and resume the sessions correctly.

The crash happened after maybe_resume_success, during the frontend Markdown rendering phase. The error looked like this:

invalid syntax at line 1 col 5

I also validated the affected JSONL files line by line. The JSONL files themselves did not contain JSON formatting errors.

Based on this, the issue appears to be:

The frontend fails to render certain historical message content, rather than the session file itself being corrupted.

Temporary Workaround

The workaround I used was to convert the executable Git inline directives in the historical messages into plain text.

The goal was to preserve useful information such as:

paths
branch names
command context
readable historical content

while preventing Codex Desktop from parsing those lines as Git action buttons or executable inline directives.

The following were not modified:

project source code
Git repository
session index

Only the affected historical session messages were adjusted.

After the modification, I revalidated the JSONL files and confirmed that they could still be parsed correctly. Then I restarted Codex Desktop, and the affected sessions opened normally again.

Impact of the Workaround

So far, this workaround has had no obvious negative impact on normal usage.

The only affected content is the small number of historical message lines that may previously have been rendered as Git operation buttons. After the fix, those lines are preserved as plain text instead.

The following content remains intact:

conversation body
tool outputs
analysis content
paths
branch information

Remaining Risk

This is only a workaround for the affected historical sessions. It does not fix the underlying Codex Desktop frontend rendering issue.

If a future session writes another similar Git inline directive containing a Windows backslash path, the same version of Codex Desktop may still trigger the same rendering error again.

If this happens, the same workaround can be applied:

Back up the affected JSONL session file.
Locate the Git inline directives containing Windows-style paths.
Convert those directives into plain text.
Validate that the JSONL file is still parseable.
Restart Codex Desktop.

I hope this helps others who run into the same issue.

MarcosRCEng · 3 months ago

I can confirm the same failure mode on another Windows Codex Desktop install.

Environment

Codex Desktop App for Windows
App package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
Codex CLI/runtime observed: 0.131.0-alpha.9
Platform: Windows x64 / PowerShell
Auth mode observed in local logs: Chatgpt
Workspace path redacted: C:\...\MyRecipeBook-develop
Branch involved: feature/fe-auth-002-auth-types

Symptom

The app frequently shows the generic Portuguese error page:

Ops, ocorreu um erro

This started after the Codex App update on 2026-05-16.

Relevant local log evidence

Log file path pattern:

%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\05\16\codex-desktop-d72effdb-491e-4426-9cbb-431948dcf552-16664-t0-i1-131532-0.log

The thread read/resume path succeeds first, then the renderer crashes:

2026-05-16T13:35:32.504Z info [AppServerConnection] response_routed ... method=thread/read ... errorCode=null
2026-05-16T13:35:37.107Z info [AppServerConnection] response_routed ... method=thread/resume ... errorCode=null
2026-05-16T13:35:37.118Z info [electron-message-handler] maybe_resume_success conversationId=019e30f9-bc43-7092-9660-d17736656165 latestTurnStatus=completed markedStreaming=true turnCount=1
2026-05-16T13:35:37.173Z error [electron-message-handler] error boundary ... name=LocalConversationPage
errorMessage="invalid syntax at line 1 col 5:

1  cwd=\"C:\\...\\MyRecipeBook-develop\" branch=\"feature/fe-auth-002-auth-types\"
       ^"

Stack includes:

markdown-D32gobzN.js
local-conversation-thread-BKrlVhAv.js
local-conversation-page-Vm2E5OJ5.js
review-file-source-tab-BmlwHNat.js
LocalConversationPage

Checked and ruled out locally

Recent logs did not show evidence of these as the primary cause:

HTTP 401 / 403 / 429 / 5xx
ENOTFOUND, ECONNRESET, ETIMEDOUT
server overloaded / JSON-RPC -32001
rate limit
DNS/proxy/network failure

Local logs showed active responses_websocket traffic and successful response events, so this looks like a frontend renderer/parsing regression rather than auth/plan/network/service outage.

Other warnings observed, likely secondary

unsupported feature enablement `auth_elicitation`
goals feature is disabled
Received turn/started for unknown conversation
Received turn/completed for unknown conversation
Windows Computer Use helper paths are unavailable

The strongest correlation is still the LocalConversationPage error boundary while parsing/rendering a cwd="C:\..." branch="..." payload after thread/resume succeeds.

Faye-663 · 3 months ago

I can reproduce the same failure mode on another Windows machine.

Environment:

Platform: Microsoft Windows NT 10.0.26200.0 x64
Codex Desktop package observed in local logs: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
App-server version reported in logs: 0.131.0-alpha.9

User-facing symptom:

Opening affected existing conversations shows the generic Chinese error page: 糟糕，出错了
Multiple historical project conversations are affected.

The local desktop logs match the renderer crash described in this issue. I see repeated LocalConversationPage error-boundary failures with:

invalid syntax at line 1 col 5:

1  cwd="D:\\Code\\GitHub\\<redacted>"
       ^

The same failure appears across multiple affected Windows workspaces, for example:

cwd="D:\\Code\\GitHub\\<redacted-a>"
cwd="D:\\Code\\GitHub\\<redacted-b>"
cwd="D:\\Code\\GitHub\\<redacted-c>"

The renderer stack also follows the same path:

markdown-*.js
local-conversation-thread-*.js
review-file-source-tab-*.js
local-conversation-page-*.js
LocalConversationPage

I also see thread/goal/get -> goals feature is disabled around the same time, but the fatal failure is the frontend renderer error boundary while parsing the cwd="..." content.

So this is an independent reproduction of the same Windows renderer/parsing crash, not only the same generic error screen. I am omitting raw local paths and full logs from the public comment, but the sanitized excerpts above are taken from local Codex Desktop logs.

shleder · 11 days ago

Because thread/resume succeeds and the underlying rollout inventory appears intact, this is a useful parser/render-vs-durable-history case for codex-rescue==0.1.0a4.

If you still have one affected rollout, could you run a read-only diagnostic:

pipx install codex-rescue==0.1.0a4
codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

It won’t fix LocalConversationPage, but it can independently check whether the durable transcript contains malformed/schema/tool-state evidence or is structurally healthy and only fails in rendering.

Please share only sanitized status/findings/aggregate counts—no raw rollout, database, prompts, tool output, credentials, repository data, conversation IDs, or private paths.

hdgevfyaw · 7 days ago

I found a deterministic content-level trigger that appears to be a narrower instance of this Windows LocalConversationPage crash.

Environment

Platform: Windows x64
Surface: Codex Desktop
App/runtime version: not captured
Affected object: an existing local conversation; new focused conversations remained usable

Minimal reproduction

Using isolated one-character UTF-8 files and opening them through the same local-file Markdown path:

Two control CJK characters render normally.
A single occurrence of Unicode code point U+73C0 in a Markdown paragraph causes the conversation page to fail.
The same code point in a plain .txt file renders normally.
A Markdown numeric entity that decodes to U+73C0 also fails, so the trigger is in the rendered result rather than the literal source text.
The same code point inside an inline-code span renders normally.

This points to a client-side Markdown/rendering-path failure for a normal text node, rather than malformed UTF-8, a missing rollout, or a whole-phrase/content rule.

Recovery validation

The affected conversation contained four occurrences in persisted assistant text.
Replacing those four occurrences with a semantically neutral safe spelling made the conversation open again.
The JSONL remained valid, with the same line count and thread identifier.
The linked Markdown document containing the code point was also repaired; the companion document had zero occurrences.

Suggested fix

Please isolate Markdown/source rendering failures behind a per-item error boundary or fallback-to-plain-text path so one valid Unicode text node cannot crash the entire historical conversation page. A regression test should cover a completed local conversation containing U+73C0 in a normal Markdown paragraph, plus the plain-text and inline-code controls.

I am not attaching the private conversation or local files, but can provide sanitized logs if needed.