Codex Desktop renderer crashes when transcript contains git directive with raw Windows cwd path

Codex Desktop renderer crashes when transcript contains git directive with raw Windows cwd path

Summary

Codex Desktop on Windows can make a thread unusable when a rendered transcript contains a Codex git app directive with a raw Windows cwd path. The affected thread opens to the generic "Oops, an error has occurred" screen. The underlying session JSONL remains valid JSON; the failure appears to happen in the Desktop renderer while interpreting historical transcript text as an app directive.

Environment

• Product: Codex Desktop
• OS: Windows
• CLI version recorded in session metadata: 0.131.0-alpha.9
• Affected local state root: C:\Users\Scott\.codex

What Happened

1. A prior assistant response included Codex git action directive text in the final answer.
2. The directive contained a raw Windows path in the cwd attribute.
3. Reopening the thread in Codex Desktop caused the main pane to show "Oops, an error has occurred".
4. A follow-up investigation thread reproduced the crash by quoting the dangerous directive text as evidence.
5. The same visible assistant answer was stored in multiple renderable JSONL records, so repairing only one occurrence was not enough.

Important Safety Note For This Report

I am intentionally not spelling the exact directive marker in this issue body because including it literally inside another Codex transcript reproduced the crash. The dangerous shape is:

[Codex git directive marker]git-<action>{cwd="<Windows drive path>", ...}

Where <Windows drive path> begins like:

C:\Users\...

The local repair script detects the exact marker internally without writing the literal marker in normal prose.

Evidence

A local findings document was created at:

C:\Users\Scott\.codex\CodexUiDirectiveCrashFindings.md

It records:

• The original broken thread id: 019e30e1-667e-7432-a4d2-2f0a7eec3a61
• The repeat investigation thread id: 019e3103-d376-7843-9cb4-13c79e97f3b7
• The documentation thread id: 019e310b-1a0c-7d82-9e67-5dd09ab925ee
• The affected rollout JSONL files under C:\Users\Scott\.codex\sessions\2026\05\16
• The observation that the same assistant content can be stored as agent_message, visible assistant message, and task_complete
• The conclusion that this is not JSONL truncation; the files parsed successfully after repair

Local Repair That Worked

A local repair script was created at:

C:\Users\Scott\.codex\Repair-CodexDirectiveCrash.ps1

The repair:

• Scans session JSONL files for the crash-signature directive plus Windows-drive cwd.
• Makes timestamped backups beside the original files.
• Replaces only the directive marker prefix with neutral text.
• Re-parses repaired JSONL line by line.
• Runs SQLite integrity checks when sqlite3 is available.

After repair, the scan reported:

remaining_crash_signatures=0

The standalone script also reported:

No Codex git-directive Windows-cwd crash signatures found.
Scan only. Re-run with -Apply to repair matching session files.

Expected Behavior

Codex Desktop should not parse arbitrary rendered transcript text as trusted app directives. If directive-like text appears in assistant/user messages, code fences, command output, or docs, it should render as inert text.

If directive parsing is still required in historical records, the parser should safely reject malformed or unsupported attributes without crashing the thread view.

Actual Behavior

The thread becomes unusable in Codex Desktop and shows:

Oops, an error has occurred

Suggested Fix

• Parse app directives only from trusted structured event records, not arbitrary rendered transcript text.
• Treat directive-looking text inside markdown/code fences/tool output as inert.
• Harden the directive parser for Windows paths in attribute values.
• Fail closed per message/component instead of taking down the whole thread view.

Attachments / Local Files Available

Additional local files can be provided if needed.