Codex Desktop crashes when clicking same-folder relative Markdown link on Windows

Open 💬 3 comments Opened Jun 30, 2026 by panikos-christofi
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop on Windows crashes/restarts when clicking a local Markdown link inside a rendered local Markdown document. This reproduces with a same-folder relative link to a synthetic Markdown file, so it does not require WSL/UNC paths, private content, parent-relative traversal, or malformed Markdown.

Environment

  • OS: Windows 11, observed Windows version string in WER output: 10_0_26200
  • Codex Desktop package observed locally: OpenAI.Codex_26.623.9142.0_x64__2p2nqsd0c76g0
  • Workspace path type: normal Windows filesystem path under C:\Users\<user>\...
  • Workspace path contains a space, for example: C:\Users\<user>\Workspace With Space\...

Minimal Privacy-Safe Repro

Create a local Markdown repro with only synthetic content:

$root = Join-Path $env:TEMP "Codex Link Repro With Space"
New-Item -ItemType Directory -Force -Path $root | Out-Null

$target = Join-Path $root "synthetic-large-transcript.md"
$index = Join-Path $root "index.md"

$lines = @(
  "# Synthetic Large Transcript",
  "",
  "This file contains no private content. It is only for local Markdown link navigation testing.",
  "",
  "## Timestamped Transcript",
  ""
)

for ($i = 1; $i -le 2600; $i++) {
  $lines += "[00:00:00.000 - 00:00:02.000] Synthetic transcript sentence number $i for renderer and navigation testing only."
}

$lines += ""
$lines += "## Plain Transcript"
$lines += ""

for ($i = 1; $i -le 800; $i++) {
  $lines += "Synthetic paragraph $i. Placeholder text for testing a markdown file of similar size without private content."
}

Set-Content -LiteralPath $target -Value $lines -Encoding UTF8

@"
# Codex Local Markdown Link Crash Repro

Click this link from inside Codex Desktop's rendered Markdown view:

[synthetic relative transcript](synthetic-large-transcript.md)
"@ | Set-Content -LiteralPath $index -Encoding UTF8

Write-Host $index
Write-Host $target
(Get-Item $target).Length

Then:

  1. Open index.md in Codex Desktop's rendered Markdown view.
  2. Click [synthetic relative transcript](synthetic-large-transcript.md).
  3. Codex Desktop crashes/restarts.

Expected Behavior

Codex should either:

  • open/render the linked Markdown file,
  • open it externally,
  • or show a handled error if this navigation is unsupported.

It should not crash or restart the desktop app.

Actual Behavior

Clicking the same-folder relative Markdown link causes Codex Desktop to crash/restart. The active turn can be interrupted.

Diagnostics Performed

The synthetic target is intentionally plain Markdown and contains no private content. In the original reproduction environment, the equivalent synthetic file had these characteristics:

  • Valid UTF-8.
  • No control characters.
  • No HTML.
  • No URLs.
  • Simple Markdown only: headings and transcript-like text lines.
  • Reproduced from a same-folder relative Markdown link.

After the synthetic-link crash, Windows Application log scans did not show a clean Codex.exe application-fault entry. The scan did show WER LiveKernelEvent / WATCHDOG entries around the time of reproduction, but those may be unrelated or too indirect to be useful.

No obvious local Codex crash logs were found under %LOCALAPPDATA%\OpenAI in the reproduction environment.

Related Issues

Related but not identical: #29347 (Windows: clicking WSL/UNC file links in chat can restart Codex Desktop). That issue concerns WSL/UNC paths emitted as chat links. This reproduction uses a normal Windows path and a same-folder relative Markdown link inside a rendered local Markdown document.

Related navigation area: #24383 (Codex Desktop: support deep links to Markdown headings from chat and rendered docs). That issue is about heading fragments opening without crashing; this issue is a crash/restart.

Suggested Fix Direction

  • Add defensive error handling around local Markdown link navigation and renderer file loading.
  • Normalize and escape Windows local paths before opening local Markdown targets, especially paths containing spaces.
  • If local Markdown file navigation is unsupported, intercept the click and show a non-crashing error/toast.
  • Add regression coverage for relative Markdown links from a rendered local Markdown document to another local Markdown file under a Windows workspace path containing spaces.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #29347
  • #30704

Powered by Codex Action

aerethiel · 1 month ago

I confirm that I also have this bug, and this happen when opening .py files as well

adamgwinn · 1 month ago

I observed a closely related variant on Windows with a generated local file link in a Codex chat message, rather than a relative link inside a rendered Markdown document.

Environment:

  • Windows 11 x64
  • Codex Desktop OpenAI.Codex_26.623.13972.0

Sanitized link shape:

[script.py (line 1)](C:/Users/<user>/<workspace>/path/to/script.py:1)

The target was a .py file. It did not exist in the currently checked-out worktree at the time of the click, although it existed on another Git ref. Clicking the rendered link caused Codex Desktop to exit/restart. I did not retry because it interrupted an active turn.

Local lifecycle evidence:

  • The previous Codex main-process log ended at 2026-07-06T08:44:24Z.
  • Windows AppModel Runtime recorded the Codex AppX container being destroyed at 08:46:34Z.
  • A new Codex container and process were created at 08:47:12Z.
  • No corresponding Codex.exe Application Error or WER crash event was recorded.

Possibly relevant, but not proven causal: the same pre-crash session repeatedly logged:

method=fs/watch
Invalid request: AbsolutePathBuf deserialized without a base path
Failed to watch open file
path=/C:/Users/<user>/<workspace>/<file>

This appears consistent with the Windows local-path normalization/error-handling family described here. It broadens the observed trigger to:

  • a chat-originated absolute drive-letter link;
  • a .py target;
  • a :1 line-number suffix; and
  • potentially a target missing from the current checkout.

Expected behavior: Codex should normalize and validate the path, or show a handled “file not found/unsupported path” error. It should never restart the desktop application.