Activity

1. hastwrkasauasksauk7-ux

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 16, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on May 16, 2026
3. github-actions commented on May 16, 2026

   

   github-actionsBot

   on May 16, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Long conversations cannot be opened at all after updating the OpenAI Windows desktop app, urgent fix needed! #22956
   • Codex Desktop session can become unusable after large Git output #22961

   Powered by Codex Action
4. Stef9332 commented on May 16, 2026

   

   Stef9332

   on May 16, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. TriS1x commented on May 16, 2026

   

   TriS1x

   on May 16, 2026

   More actions

   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:

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

   I hope this helps others who run into the same issue.
6. MarcosRCEng commented on May 16, 2026

   

   MarcosRCEng

   on May 16, 2026 – with ChatGPT Codex Connector

   More actions

   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.
7. Faye-663 commented on May 16, 2026

   

   Faye-663

   on May 16, 2026 – with ChatGPT Codex Connector

   More actions

   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.
8. hdgevfyaw commented on Aug 20, 2026

   

   hdgevfyaw

   on Aug 20, 2026 – with ChatGPT Codex Connector

   More actions

   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:

   1. Two control CJK characters render normally.
   2. A single occurrence of Unicode code point U+73C0 in a Markdown paragraph causes the conversation page to fail.
   3. The same code point in a plain .txt file renders normally.
   4. 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.
   5. 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.
9. MajeauDesigns commented on Sep 23, 2026

   

   MajeauDesigns

   on Sep 23, 2026 – with ChatGPT Codex Connector

   More actions

   Independent Windows reproduction on a current Sep 23 build. This looks closer to this issue than #30826.

   Environment

   • Codex desktop / ChatGPT Windows app
   • Displayed version: 26.917.62051
   • Windows package observed in crash dump: OpenAI.Codex_26.917.8451.0_x64

   Symptom

   • One specific historical Codex chat crashes the entire app immediately when clicked.
   • The project itself is fine.
   • A new chat in the same project opens and works normally.
   • A brand-new short-path project also works normally.
   • In the minimal project, completed changes to .txt, .md, and .py files all opened from the review UI without crashing.

   Affected rollout

   I inspected a copied local rollout for the affected historical chat:

   • ~20.9 MB JSONL
   • 1,729 JSONL records
   • 0 malformed JSON records
   • no obvious truncation / null-byte corruption
   • 57 embedded images totaling roughly 13.8 MB of Base64 image data
   • several individual tool-output records over 1 MB
   • one compacted-history record around 2.66 MB

   Normal conversational activity in that rollout ended earlier in the month. When the affected chat is opened on the current build, new thread_settings_applied events are appended, then the Windows app terminates before the conversation UI becomes usable.

   Crashpad

   A Crashpad dump is generated. Initial dump inspection shows:

   • Process: ChatGPT.exe
   • Crashing thread: CrBrowserMain
   • Faulting module: chrome.dll
   • Exception: 0x80000003

   This suggests a renderer/UI restore failure for one existing historical session rather than a workspace/file-type problem. The durable JSONL itself appears structurally valid.

   I am intentionally not posting the raw rollout, session identifier, private paths, or dump publicly. They are available through private support/in-app feedback if needed.