Long conversations cannot be opened at all after updating the OpenAI Windows desktop app, urgent fix needed!
What version of the Codex App are you using (From “About Codex” dialog)?
26.513.31313
What subscription do you have?
APIKEY
What platform is your computer?
Microsoft Windows NT 10.0.19045.0 x64"Microsoft Windows NT 10.0.19045.0 x64
What issue are you seeing?
<img width="674" height="451" alt="Image" src="https://github.com/user-attachments/assets/a4a59e03-ddfd-4c89-ac5b-dbe3fe129a1b" />
After seeing an update prompt in the top-left corner of the Codex desktop app, I clicked update and restarted. Afterward, the long conversations I had been working on would no longer load. I have several ongoing conversations with rollout files around 150M-170M, and I can't open any of them. When I try to open them, the error message shown in the image above appears, and clicking the retry button or restarting the app has no effect.
Before this update, my conversations were working completely normally.
After the update, my shorter conversations can still be opened as usual, but these long conversations repeatedly show this error no matter what I do. Please resolve this as soon as possible!!
What steps can reproduce the bug?
Feedback ID: 019de1dc-b9f5-7b81-871c-c252412e1832
What is the expected behavior?
Able to open very long conversations normally
Additional information
_No response_
22 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Me too!!!
This started right after I updated the Windows Codex app, and now almost all of my conversations won’t open.
After clicking “Update,” I encountered the same issue and couldn't resume my previous session.
<img width="706" height="431" alt="Image" src="https://github.com/user-attachments/assets/34402c21-e85b-4223-af7e-70b31f15facb" />
This has basically made the codex app unusable. Even newly created conversations can randomly hit this bug, and I’m not sure what triggers it yet.
Mismo error ya no puedo abrir los chats en los que estaba trabajando, esto paso despues de actualizar la aplicacion de escritorio en windows el dia de hoy.
<img width="725" height="426" alt="Image" src="https://github.com/user-attachments/assets/ad47eb65-521c-454f-b105-24a891879224" />
Me too. Right after I updated my codex app, one of the project that I was working on does not load and says: Oops, an error has occurred
<img width="583" height="305" alt="Image" src="https://github.com/user-attachments/assets/117f17b0-7310-491c-a0a1-67105c0d065c" />
Same here!
<img width="304" height="210" alt="Image" src="https://github.com/user-attachments/assets/3a2f3c7a-3d30-484f-b9a2-32839bdccd4f" />
me too,codex can not work
I can reproduce this on Windows Codex Desktop 26.513.31313. New conversations work, but older resumed conversations show the error page. This started immediately after updating Codex Desktop.
Code Apps logs show the error like bellow, i think it is about markdown and windows like path
I can work now, please fix it now !
2026-05-16T06:00:41.706Z error [electron-message-handler] error boundary componentStack="\n at Br (app://-/assets/markdown-D32gobzN.js:8:5425)\n at div (<anonymous>)\n at uy (app://-/assets/local-conversation-thread-BKrlVhAv.js:32:229104)\n at HS (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:69831)\n at div (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at Rw (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:151035)\n at app://-/assets/local-conversation-thread-BKrlVhAv.js:34:148809\n at Xw (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:167685)\n at div (<anonymous>)\n at app://-/assets/local-conversation-thread-BKrlVhAv.js:34:175039\n at div (<anonymous>)\n at div (<anonymous>)\n at rT (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:169305)\n at div (<anonymous>)\n at a (app://-/assets/proxy-BjzPZxH5.js:1:9079)\n at nE (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:200109)\n at div (<anonymous>)\n at div (<anonymous>)\n at a (app://-/assets/proxy-BjzPZxH5.js:1:9079)\n at div (<anonymous>)\n at div (<anonymous>)\n at f (app://-/assets/thread-scroll-layout-Cxloffmz.js:1:743)\n at div (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at s (app://-/assets/thread-layout-Chou_aJz.js:1:243)\n at fT (app://-/assets/apps-C0n7YO22.js:76:5536)\n at XT (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:192696)\n at qT (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:190451)\n at WT (app://-/assets/local-conversation-thread-BKrlVhAv.js:34:188762)\n at div (<anonymous>)\n at div (<anonymous>)\n at rn (app://-/assets/local-conversation-page-Vm2E5OJ5.js:2:30978)\n at pn (app://-/assets/local-conversation-page-Vm2E5OJ5.js:2:38605)\n at Re (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:4057)\n at tt (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:8269)\n at Suspense (<anonymous>)\n at Zn (app://-/assets/app-shell-D5Aq-LSR.js:1:52215)\n at div (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at main (<anonymous>)\n at div (<anonymous>)\n at div (<anonymous>)\n at a (app://-/assets/proxy-BjzPZxH5.js:1:9079)\n at jn (app://-/assets/app-shell-D5Aq-LSR.js:1:44586)\n at $n (app://-/assets/app-shell-D5Aq-LSR.js:1:52694)\n at Hw (app://-/assets/app-main-1fJkJDdR.js:2:297978)\n at Uw (app://-/assets/app-main-1fJkJDdR.js:2:300152)\n at Vw (app://-/assets/app-main-1fJkJDdR.js:2:297651)\n at Ww (app://-/assets/app-main-1fJkJDdR.js:2:300261)\n at Re (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:4057)\n at tt (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:8269)\n at fD (app://-/assets/app-main-1fJkJDdR.js:4:34174)\n at Re (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:4057)\n at it (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:9374)\n at Suspense (<anonymous>)\n at Dn (app://-/assets/vscode-api-BEuchX0L.js:1:50266)\n at UI (app://-/assets/app-main-1fJkJDdR.js:60:16708)\n at Dn (app://-/assets/vscode-api-BEuchX0L.js:1:50266)\n at BI (app://-/assets/app-main-1fJkJDdR.js:60:14900)\n at UM (app://-/assets/app-main-1fJkJDdR.js:4:215494)\n at VM (app://-/assets/app-main-1fJkJDdR.js:4:213673)\n at fT (app://-/assets/apps-C0n7YO22.js:76:5536)\n at OM (app://-/assets/app-main-1fJkJDdR.js:4:207866)\n at IO (app://-/assets/app-main-1fJkJDdR.js:4:99126)\n at Qu (app://-/assets/WorkerPoolContext-9g15HyMX.js:168:29293)\n at x (app://-/assets/shiki-highlight-provider-DgU-gB_m.js:1:671)\n at Suspense (<anonymous>)\n at qI (app://-/assets/app-main-1fJkJDdR.js:60:18059)\n at kF (app://-/assets/app-main-1fJkJDdR.js:7:50846)\n at w (app://-/assets/tooltip-q1BAjA5f.js:1:1084)\n at sM (app://-/assets/app-main-1fJkJDdR.js:4:189572)\n at YO (app://-/assets/app-main-1fJkJDdR.js:4:103251)\n at t (app://-/assets/global-settings-DxHTPSP4.js:26:8362)\n at KM (app://-/assets/app-main-1fJkJDdR.js:4:216031)\n at p (app://-/assets/statsig-C9zAUV2g.js:1:3388)\n at l (app://-/assets/statsig-C9zAUV2g.js:1:2720)\n at iA (app://-/assets/app-main-1fJkJDdR.js:4:135367)\n at rA (app://-/assets/app-main-1fJkJDdR.js:4:134435)\n at yP (app://-/assets/app-main-1fJkJDdR.js:7:6138)\n at $O (app://-/assets/app-main-1fJkJDdR.js:4:107727)\n at HM (app://-/assets/app-main-1fJkJDdR.js:4:214129)\n at rt (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:8456)\n at $e (app://-/assets/chunk-LFPYN7LY-DRAAscIQ.js:3:7211)\n at RI (app://-/assets/app-main-1fJkJDdR.js:60:14401)\n at Dn (app://-/assets/vscode-api-BEuchX0L.js:1:50266)\n at En (app://-/assets/vscode-api-BEuchX0L.js:1:50104)\n at jF (app://-/assets/app-main-1fJkJDdR.js:7:51590)\n at Mt (app://-/assets/app-server-manager-signals-BEaGjuc8.js:2:1681)\n at Vn (app://-/assets/vscode-api-BEuchX0L.js:1:54178)\n at xI (app://-/assets/app-main-1fJkJDdR.js:60:4414)\n at ek (app://-/assets/app-main-1fJkJDdR.js:4:109316)\n at cI (app://-/assets/app-main-1fJkJDdR.js:60:1331)\n at LI (app://-/assets/app-main-1fJkJDdR.js:60:9643)" errorMessage="invalid syntax at line 1 col 5:\n\n1 cwd=\"C:\\Users\\my_project_path\"\n ^" errorName=Error errorStack="Error: invalid syntax at line 1 col 5:\n\n1 cwd=\"C:\\Users\\my_project_path\"\n ^\n at app://-/assets/vscode-api-BEuchX0L.js:1:58787\n at ur (app://-/assets/vscode-api-BEuchX0L.js:1:56867)\n at fr (app://-/assets/vscode-api-BEuchX0L.js:1:57070)\n at Lu (app://-/assets/review-file-source-tab-BmlwHNat.js:9:117380)\n at _u (app://-/assets/review-file-source-tab-BmlwHNat.js:9:112540)\n at gu (app://-/assets/review-file-source-tab-BmlwHNat.js:9:112046)\n at ld (app://-/assets/review-file-source-tab-BmlwHNat.js:9:123129)\n at app://-/assets/review-file-source-tab-BmlwHNat.js:9:123182" name=LocalConversationPage
github comment my handle the path bad, the real log content like this
<img width="3014" height="56" alt="Image" src="https://github.com/user-attachments/assets/d4a930ca-1756-4fe2-8e79-03c2662a8f9e" />
Same issue. This is my understanding/post in reddit:
So I updated (DUMB) and I keep getting errors when trying to push to git that causes threads to stop being able to be pulled up.
Doing a lot of debugging and work arounds but it's miserable. This is codex's most recent assessment:
It keeps happening when a thread does a successful git stage/commit/push and Codex writes its special UI directives into the final assistant message.
For ((removed by me)), it is not that our previous fix failed. That thread had been fixed earlier, then later continued working and pushed a new backend commit:
((removed by me)) Add recipe embedding text builder
After that push, Codex appended new lines like:
::git-stage{cwd=((removed by me))
::git-commit{cwd=((removed by me))
::git-push{cwd=((removed by me))
Those are fresh, at the very end of the thread. Same kind of thing happened to the banana thread after it pushed aa25e32, and removing the fresh lines fixed it again.
So the pattern is:
Old/new thread is clean.
Thread runs git stage/commit/push.
Codex Desktop appends ::git-*{cwd="C:\..."} directives into saved assistant-visible messages.
Current Windows renderer tries to parse them.
Renderer crashes on raw C:\... syntax.
The underlying cause is the app bug: Codex Desktop is still generating or re-rendering directives with Windows paths in a syntax its own parser cannot handle. Until OpenAI patches that, any thread that does a git action may re-break after the final response.
Best practical workaround: don’t do commits/pushes inside old important threads for now. Use a fresh disposable “git push” thread, or I can do git work but avoid emitting the final Codex git directives where possible. For the already-broken Prepare AI recipe matching thread, the same 9-line sanitizer should restore it.
Adding another Windows repro from a separate machine/account.
Environment:
OpenAI.Codex_26.513.3673.0version.jsonreports latest version check:0.130.0Observed behavior:
Oops, an error has occurred.Try againdoes not recover the thread.Local transcript diagnostics:
019e2e25-aeee-78a1-80d8-3e4ab536b566ruff check .passing andpytestpassing (53 passed).Relevant local log signals around the same time window:
chatgpt.com/backend-api/plugins/...returned403 Forbiddenwith a Cloudflare/JavaScript challenge page.failed to back up plugin cache entry: Access is denied. (os error 5).My read: this does not look like repository corruption or invalid JSONL. It looks like a Desktop renderer/session-resume regression after the Windows app update, affecting long or interrupted local threads. The session file is valid but the Desktop UI cannot render/resume it.
I intentionally omitted full local filesystem paths and full log payloads from this public comment, but can provide more sanitized diagnostics if useful.
Same here! Using the $100/m sub, not API on Windows 10.
(Codex summarized the troubleshooting we did below:)
Adding another Windows repro with a useful comparison: not every older/longer thread crashes after this update.
Environment:
26.513.31313OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0Oops, an error has occurredpage.Important detail: total rollout size alone does not explain it.
I compared three local rollout files:
| Thread behavior | Rollout size | Max single JSONL record | Compacted records | Inline image refs |
session_metarecords |cli_version||---|---:|---:|---:|---:|---:|---|
| Works: I can scroll entire thread | 11.68 MB | 0.66 MB | 3 | 184 | 1 |
0.123.0-alpha.5|| Fails/errors while scrolling | 13.37 MB | 2.37 MB | 2 | 44 | 67 |
0.130.0-alpha.5|| Fails/errors while scrolling | 61.09 MB | 9.77 MB | 6 | 94 | 94 |
0.130.0-alpha.5|So this does not look like a simple “long thread over X MB” threshold. One working thread is almost the same total size as one failing thread, and it actually has more inline image references overall.
The pattern I’m seeing locally is that the failing newer sessions have:
compactedrecordssession_metarecordscli_versionaround0.130.0-alpha.5The working older thread has many images too, but the records are smaller and it only has one
session_meta.This may be related to renderer hydration / markdown rendering / compacted-history rendering rather than just raw rollout size. It would be useful if the app could tolerate large individual records or skip/render-placeholder for problematic compacted records instead of sending the whole thread to the generic error page.
Feedback ID: f2fafff7-ee83-4b17-8260-34fd61ca9f41
<img width="605" height="396" alt="Image" src="https://github.com/user-attachments/assets/e00e1c4f-3672-4941-adf2-890d2dd9459b" />
一样
This solved it for me.
I made Codex investigate the issue and create a fix based on your comment, and it fixed it ... kind of!
The script below takes a thread GUID and sanitises it. It can be used for recovering an important thread.
(below this line is generated by Codex to publicly share here)
In my case, there were two separate problems:
The script below creates a renderer-safe recovery clone of a selected thread. It does not modify the original rollout file. It can also scan a thread and report only counts/field paths, without printing the risky matched text.
Usage examples:
Important notes:
Codex/codexprocesses.state_5.sqliteandsession_index.jsonl.<details>
<summary>recover-codex-long-thread.ps1</summary>
</details>
Machine-wide directive I added locally to avoid creating new bad saved text:
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 error has occurredCheck for updatesTry againIn 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
cwdparameter like: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/readandthread/resumecompleted 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: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:
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:
while preventing Codex Desktop from parsing those lines as Git action buttons or executable inline directives.
The following were not modified:
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:
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:
I hope this helps others who run into the same issue.
https://github.com/openai/codex/issues/22984#issuecomment-4466400904
This solution worked for me. After giving the prompt to Codex to execute and restarting the Codex app, it fixed all the sessions I couldn't open before.
Still hoping the Codex team can release a real fix for this bug so it doesn't happen again.
For anyone blocked by this right now, here’s a workaround prompt you can paste into Codex CLI. It does not patch the WindowsApps installation in place. It makes a writable local copy of the Codex app and patches that copy, because editing
C:\Program Files\WindowsAppsdirectly is painfully locked down on Windows.Likely root cause for maintainers: the directive attribute parser’s quoted-string regex appears to mishandle Windows paths like
cwd="C:\...". A backslash escape followed by normal characters can fail tokenization, which surfaces asinvalid syntax at line 1 col 5.Prompt:
`````md
Fix the Codex Desktop Windows render crash caused by old Git directives.
Context:
Old conversations may contain directives like:
The current webview bundle can crash while parsing those Windows backslashes with:
Known original ASAR integrity hash for this build:
Task:
appdirectory to a writable patch location, for example:Do not modify
C:\Program Files\WindowsAppsdirectly.to a temporary working directory.
Use this exact-string replacement script. It writes to a separate output file and refuses in-place overwrite:
Then replace the extracted bundle file with the generated output file.
Verify syntax:
Do not use
app.asar.unpackedfor this fix.Codex.exeonce. It should fail with an ASAR integrity error like:For this build,
old_hashshould be:Patch only the copied
Codex.exeby replacingold_hashwithnew_hashusing this binary-safe script:`````
We've issued a hotfix to address this. Please update to the latest version.
Thank you! Can confirm it works!