›_ Codex Issues
Codex Issues / #22968

Codex Desktop session fails to open when git directives contain Windows paths

Resolved 💬 6 comments Opened May 16, 2026 by Nitmi Closed May 16, 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.513.31313

What subscription do you have?

Not relevant / not known.

What platform is your computer?

Windows 10.0.28000, x64

Runtime: Electron 42.0.1

Locale: zh-CN

Shell: PowerShell

Affected session source: vscode

What issue are you seeing?

Codex Desktop can fail to open an existing session when the session history contains assistant messages with raw git UI directives such as:

::git-stage{cwd="D:\project\multiProject\XM00029\XM00029_software_Back-end"}
::git-commit{cwd="D:\project\multiProject\XM00029\XM00029_software_Back-end"}

When reopening the session, the renderer attempts to parse these lines as Markdown directives and throws a syntax error. The session resume request appears to succeed on the backend, but frontend rendering fails, making the session unusable from the UI.

Related to #22956, but this report isolates the suspected trigger: standalone ::git-*{cwd="C:\..."} directive lines with Windows paths in historical assistant-visible Markdown.

The affected session characteristics:

  • The session rollout file was valid JSONL and could be parsed line by line.
  • The workspace path existed and was accessible.
  • The session contained many assistant messages with raw git directives emitted as visible Markdown text.
  • Some directive paths used Windows backslashes, for example D:\project\....
  • The same session could be repaired by removing standalone ::git-stage{...} and ::git-commit{...} lines from rendered message text.

The app-side Sentry scope / renderer logs recorded this error:

Error: invalid syntax at line 1 col 5:

1  cwd="D:\project\multiProject\XM00029\XM00029_software_Back-end"
       ^

Stack trace excerpt:

at S._token (.../app-server-manager-signals-*.js)
at Object.tokenizer (.../app-server-manager-signals-*.js)
at marked.esm-*.js
at Br (.../markdown-*.js)

Backend resume logs showed only a PowerShell shell snapshot warning, which appears unrelated:

thread/resume ... Failed to create shell snapshot for powershell:
Shell snapshot not supported yet for PowerShell

No JSONL corruption was found.

What steps can reproduce the bug?

  1. Use Codex Desktop on Windows.
  2. Create or edit a session history so an assistant message contains a standalone line like:
::git-stage{cwd="D:\project\repo"}
  1. Close/reopen or resume the session.
  2. Observe that the renderer throws a Markdown directive syntax error while parsing the cwd=... attribute.

What is the expected behavior?

Codex Desktop should open the session normally.

If a Markdown directive is malformed or contains unsupported attribute syntax, the renderer should degrade gracefully by rendering it as plain text or ignoring only that directive. A single parse error in historical assistant output should not make the entire session impossible to open.

What is the actual behavior?

The frontend Markdown renderer throws during parsing and the session cannot be opened normally.

Suspected root cause

There are likely two product-side issues:

  • Codex-generated git directives are emitted into normal assistant Markdown history, rather than stored or handled as structured metadata that is safe to replay.
  • The Markdown directive parser does not tolerate Windows paths/backslashes in directive attributes and allows a directive parse error to break rendering of the whole session.

The crash trigger appears to be standalone directive syntax with a Windows path:

::git-stage{cwd="D:\project\repo"}

Forward-slash paths such as D:/project/repo appear less risky, but the renderer should still not crash on invalid directive syntax.

Workaround used

The affected rollout JSONL was repaired by:

  1. Backing up the original session file.
  2. Parsing each JSONL line as JSON.
  3. Recursively removing standalone lines matching:
::git-stage{cwd=...}
::git-commit{cwd=...}
  1. Rewriting the JSONL.
  2. Re-validating that all JSONL lines parse successfully and no standalone git directive lines remain.

After this cleanup, the session file remained valid and the problematic rendered text was gone.

Suggested fix

  • Make Markdown directive parsing fail-soft: malformed directives should render as text, not crash the conversation view.
  • Escape, normalize, or disallow raw Windows paths in directive attributes before storing them in assistant-visible Markdown.
  • Prefer storing git UI events as structured metadata instead of raw assistant message text.
  • Add regression tests for replaying historical sessions containing:
::git-stage{cwd="D:\project\repo"}
::git-commit{cwd="D:\project\repo"}

Impact

This makes long-running Codex sessions unrecoverable from the UI even though their rollout files are not corrupt. Users may lose access to important project history unless they manually edit internal .codex session files.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

  • #22963

Powered by Codex Action

GiorgiKemo · 2 months ago

Independent confirmation from another Windows machine. This is the same root cause, and the local repair confirms the trigger is the stored git directive text rather than git/repo corruption.

Environment observed locally:

  • Codex Desktop package: OpenAI.Codex_26.513.3673.0_x64__2p2nqsd0c76g0
  • Desktop/runtime log release: 26.513.31313
  • Session cli_version: 0.131.0-alpha.9
  • Platform: Windows x64, PowerShell
  • Workspace path pattern: C:\Users\<user>\Desktop\OG Websites\public

What happened:

  • The original task completed successfully.
  • npm.cmd run build passed.
  • The commit was created and pushed to GitHub.
  • Immediately after the final assistant message, reopening/rendering the completed thread showed the generic Codex Desktop error page.

Local log evidence:

2026-05-16T08:21:57.836Z error [electron-message-handler] error boundary ... name=LocalConversationPage
errorMessage="invalid syntax at line 1 col 5:

1  cwd=\"C:\\Users\\<user>\\Desktop\\OG Websites\\public\"
       ^"

Stack fragments in the same error boundary:

markdown-D32gobzN.js
local-conversation-thread-BKrlVhAv.js
review-file-source-tab-BmlwHNat.js
marked.esm-B1dI5d9h.js

In the affected rollout JSONL, the bad git directive block appeared in three persisted places:

  • final event_msg.payload.message
  • final response_item.payload.content[0].text
  • task_complete.payload.last_agent_message

Local mitigation that fixed the thread:

  1. Close Codex Desktop so the rollout JSONL is not locked.
  2. Back up the affected session file.
  3. Remove only the standalone git directive block from those three persisted message strings.
  4. Keep the human-readable final result text unchanged.
  5. Reopen Codex Desktop.

Result: the thread rendered normally again. The repair log showed Removed directive blocks: 3, and a follow-up scan found no remaining rendered Windows-path git directive block in that thread.

Suggested product fix:

  • Make the Markdown/directive tokenizer fail-soft. A malformed directive should render as text or be skipped, not throw through LocalConversationPage.
  • Do not persist git UI action directives only as assistant-visible Markdown. Store them as structured metadata, or ensure replay uses a safe renderer.
  • Normalize/escape Windows paths before writing directive attributes. Forward-slash paths appear safer, but parser hardening is still needed.
  • Add a regression test for replaying a completed Windows session whose final assistant text contains git UI directive lines with a backslash cwd path and a branch attribute.

This confirms the issue is not caused by git add, git commit, git push, or a corrupt repo. It is a replay/rendering failure for stored directive-shaped assistant text on Windows.

GiorgiKemo · 2 months ago

Update after further local investigation and mitigation:

I found this was not limited to one broken transcript. On the affected Windows machine, the same renderer-triggering pattern existed across saved Codex history:

  • Scanned 288 saved transcript files under the local Codex data directory.
  • Repaired 91 transcript files.
  • Removed 7,902 marker-shaped git action snippets containing Windows drive-letter paths.
  • Revalidated after repair: 0 remaining bad marker candidates, 0 JSONL parse errors.

A local guard was also added so future assistant-visible output on that machine avoids emitting raw git action directive-shaped text with Windows paths. That prevents the local recurrence, but it is only a workaround. The app renderer can still be made unrecoverable by persisted historical chat/tool text that happens to look like one of these internal directives.

Updated suggested fix direction:

  1. Treat persisted assistant/tool Markdown as untrusted input during replay. A directive parse failure should be isolated to that block and rendered as inert/plain text or replaced with a recoverable placeholder, not crash the whole thread view.
  2. Keep Codex UI action metadata out of assistant-visible Markdown where possible. If git action markers need to exist, persist them as structured metadata rather than reparsing raw message text.
  3. Add Windows regression coverage for replaying old transcripts containing marker-shaped git action text with drive-letter/backslash paths inside attributes.
  4. Add a recovery path that lets the user open/export the thread even if one historical block cannot be parsed.
  5. When emitting future git action markers on Windows, normalize or escape paths before rendering/parsing so path separators and drive-letter colons cannot break directive parsing.

The important new finding is scale: once this pattern exists in saved history, fixing only the currently selected thread is not enough. Any old thread containing the same marker-shaped text can re-trigger the same generic “Oops, an error has occurred” screen later.

Nitmi · 2 months ago

I made a small Windows-only local repair tool for this issue:

Repository: https://github.com/Nitmi/codex-session-doctor

Direct download: https://github.com/Nitmi/codex-session-doctor/releases/download/v1.0.0/Codex.Session.Doctor.exe

Release page: https://github.com/Nitmi/codex-session-doctor/releases/tag/v1.0.0

What it does:

  • Scans local Codex session JSONL files.
  • Removes the persisted standalone ::git-*{cwd="C:\..."} marker lines that trigger the renderer crash.
  • Backs up every changed file before writing.
  • Provides a broader repair mode for all standalone git markers if the default repair is not enough.
  • Runs as a standalone Windows .exe; no Node.js, Bun, Go, or other runtime required.

This is only a local workaround so users can recover existing broken sessions while waiting for the product-side fix. The product still needs to make Markdown/directive parsing fail-soft and avoid persisting UI git markers as assistant-visible Markdown.

Faye-663 · 2 months ago

I can reproduce what looks like the same issue 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 logs match the renderer failure described here. I see repeated LocalConversationPage error-boundary crashes with:

invalid syntax at line 1 col 5:

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

Examples from separate affected workspaces on the same machine all fail with the same shape:

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

The stack also goes through the same renderer 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-path / directive-rendering failure mode, not just the generic error screen. I am omitting raw paths and full logs from the public comment, but sanitized excerpts above are from the local desktop logs.

etraut-openai contributor · 2 months ago

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