Codex Windows App Renders Local File Paths Incorrectly, Breaking File and Folder Links

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

• #13548

Powered by Codex Action

I hit what looks like the same Windows app local-link parsing bug on a newer build (26.306.996.0, Windows 10.0.26200.0 x64, ChatGPT Plus), and I have a more detailed repro matrix that may help narrow the parser behavior.

Additional observations:

• Only Unix-style </Users/...> links are treated as real local path objects in the Codex UI on Windows (right-click includes Copy path, clicking opens the correct file).
• <C:/Users/...> and <C:\\Users\\...> render blue/underlined but behave like styled text only: no path metadata / no Copy path / clicking does not open the file.
• <\\Users\\...> gets percent-encoded into %5CUsers%5C....
• <//Users/...> is interpreted as a host/UNC-style URI, and VS Code prompts that host Users is not in the allowlist.
• <///C:/Users/...> and <///D:/...> open VS Code, but the resolved path is prefixed with the current drive, e.g. C:\\C:\\Users\\... or C:\\D:\\..., so an empty file is opened instead of the real file.
• Long non-ASCII paths on F: also become garbled / percent-encoded and do not open correctly.

So this seems broader than just /C:/... rendering: the app appears to recognize only a narrow Unix-style local-path form on Windows, while drive-letter absolute paths, backslash paths, and UNC-like forms are all mis-handled in different ways.

I filed #14483 with the full repro matrix and will close it as a duplicate of this issue to keep discussion in one place.

Additional repro data from more controlled tests on the same Windows machine:

Two separate failure modes are now confirmed.

1) Drive-letter absolute paths fail even when the path is pure ASCII

These were tested against real existing files with ASCII-only path segments:

[A](<C:/Users/28033/.codex/tmp/link-tests/ascii.md>)
[B](<D:/.codex_shortfiles/link-tests/ascii.md>)
[C](<F:/.codex_shortfiles/link-tests/ascii.md>)
[D](</Users/28033/.codex/tmp/link-tests/ascii.md>)

Observed behavior:

• A, B, C: render blue / underlined, but are not treated as real path objects by the app.
• no path hover / metadata
• no Copy path in the context menu
• clicking does not open the file
• D: works correctly
• opens the file
• is treated as a path object in the UI
• context menu includes Copy path

So this is not just a non-ASCII problem: drive-letter absolute paths appear unsupported / misparsed by the Windows app even when they are otherwise simple ASCII paths.

2) Any non-ASCII path segment appears to break clickable path targets

I also tested combinations where only one variable changed at a time:

• ASCII dir + Chinese filename
• Chinese dir + ASCII filename
• Chinese dir + Chinese filename

Across C:, D:, and F:-backed clickable paths, the result was the same:

• as soon as any path segment contains Chinese characters, the target becomes percent-encoded (%...) and does not open correctly
• only the all-ASCII variant works reliably

This suggests two distinct app-side parsing problems on Windows:

1. drive-letter absolute paths are not being recognized as proper local file targets
2. non-ASCII path segments in otherwise-valid clickable paths are being URL-encoded into unusable local targets

Current workaround on my side is to expose source files through ASCII-only alias paths, but that is only a workaround.

One short clarification to avoid confusion from earlier wording: the %... target garbling is not a generic long-path issue. It reproduces when any clickable path segment is non-ASCII (for example Chinese directory names or filenames). Separately, drive-letter absolute paths still fail even when the entire path is ASCII-only.

For completeness, here is the current workaround I am using on Windows. This is not a fix, just a way to keep file links usable in day-to-day work:

• keep the final clickable chat target ASCII-only
• for files, expose the same source file through an ASCII-only alias path (same-volume hardlink alias)
• for directories, expose the source directory through an ASCII-only junction alias under a C:\Users\... path that the app can actually open

This avoids both current failure modes:

• drive-letter absolute paths in chat are not handled correctly
• non-ASCII path segments become percent-encoded and fail to open

The workaround preserves source-file semantics, but it adds extra alias-management overhead and should not be necessary if the app handled Windows local paths correctly.

One more clarification on the workaround: it also has to avoid drive-letter paths in the final chat link target, not just non-ASCII path segments.

What I am doing in practice is:

• for source files on non-C: volumes (D:, F:, etc.), create an ASCII-only alias on the same volume, then expose that alias through a chat-clickable path form instead of linking D:/... or F:/... directly
• for source directories on non-C: volumes, expose them through an ASCII-only junction path under a C:\Users\... tree that the app can actually open

So the workaround is solving two separate app-side limitations at the same time:

1. direct drive-letter paths in chat do not work reliably on Windows
2. non-ASCII path segments in clickable targets get percent-encoded and fail

In other words, the final clickable chat target must avoid both drive-letter absolute forms and non-ASCII segments.

Related issues that seem to belong to the same local-file-link / path-normalization bug family:

• #13548: older Windows desktop symptom where local file references resolved to invalid c:\\C:\\... paths
• #13123: desktop app fails to open URL-encoded local paths with Chinese / non-ASCII path segments

From current repros on my machine, #14079 appears to sit at the intersection of both:

• direct drive-letter paths in Windows chat links are not treated as proper local file targets
• non-ASCII path segments in local link targets become percent-encoded and fail to open correctly

So this does not look like one isolated formatting issue, but rather a broader app-side local-path parsing / normalization problem.

I can reproduce this on a newer Windows Codex app build as well.

Environment:

• App version: 26.311.2262.0
• Platform: Windows 11

Symptom:

• Codex renders a generated local filename/path in blue underlined text, so it looks clickable.
• Clicking it does nothing at all.
• In my case this happens for generated output filenames shown in the chat, for example a CSV output file reference after a task completes.

Expected behavior:

• If it is a file reference, click should open the file directly.
• If direct open is not possible, it should open the containing folder and highlight the file.
• If the app cannot resolve the target, it should not render it as an interactive-looking link without any action.

This still reproduces for me on 26.311.2262.0, so it does not appear to be fixed in newer Windows builds.

I dug into the current Windows app package on my machine (OpenAI.Codex 26.311.2262.0) and found a bit more signal.

This does not look like a generic "blue text only" styling issue.

What the packaged app is doing:

• In the webview bundle, file references are rendered through a dedicated file-reference component, not a plain anchor.
• Left-click calls an internal open-file action.
• The file-reference context menu also has a reveal action that calls open-file with target: fileManager.
• In the main bundle on Windows, the app has explicit Explorer fallback logic using showItemInFolder(...) and then openPath(...) if needed.
• The same package also has built-in Antigravity target detection on Windows, so this is not just "editor target unknown" in my case.

That points more toward path/target resolution failing downstream for some references, rather than the renderer merely making non-links look clickable.

My repro is still the same:

• Codex prints a blue underlined local filename in the response
• example looked like submission-template_The-Greyhound-Whisperer_2026-03-13.csv
• clicking it does nothing in the Windows app

So the likely issue seems to be one of:

• the generated reference/path is incomplete or not resolvable in that thread context
• open-file resolution is failing silently
• target resolution is failing without surfacing an error

@phillza This is very helpful and matches what I observed on my side.

On my Windows repros, there seem to be at least two failure surfaces in the same pipeline:

• some path forms never become real file-path objects in chat at all (for example drive-letter absolute targets like <C:/...>, <D:/...>, <F:/...>)
• and for other cases, especially when any path segment is non-ASCII, the target appears to make it further downstream but then fails during resolution / open

So your findings about a dedicated open-file flow plus silent downstream failure fit very well with the behavior I am seeing. This really does look like a Windows local-file-link pipeline bug, not just a styling issue.

I can reproduce a closely related Windows path problem in the desktop app.

In my session, assistant responses included absolute local paths such as:

/E:/Test/novel-writing-platform/docs/home-client-preview.png

Two things happened:

1. local file links in the response were not clickable/openable from the app UI
2. local markdown image references using the same absolute path format did not render inline, even though the PNG existed on disk

So from the user side this looks broader than just "open file/folder" failing. The /DriveLetter:/... path format also seems to break local asset rendering and message link affordances in the Windows desktop app.

Additional narrower repro on Windows 11, Codex app version 26.313.4956.0:

In the same message, a blue local-file link whose visible label was just file successfully opened File Explorer.

But two adjacent blue links whose visible text started with absolute Windows paths like C:\... did nothing when clicked.

So this does not look like "all local file links are broken" equally. It looks like Codex is parsing/rendering at least two different kinds of blue local-link UI on Windows:

• short label-only local file refs can work
• absolute C:\... style refs can still render blue but do not trigger an open action

That may help narrow it to how absolute Windows drive paths are classified in the markdown/render layer before they reach the normal local open-file path.

Correction to my previous narrowing:

I can also reproduce a blue workspace-relative file link that resolves correctly on hover but still does nothing on click.

Example pattern: a link like src/margin combo model.py showed the expected resolved file path on hover, but clicking it still did not open anything.

So the bug is not just "absolute C:\... paths are broken while relative paths work".

The more accurate behavior is:

• Codex can often resolve the target path well enough to render a blue local-file-looking control and show the correct tooltip/hover path
• but the click still sometimes fails to trigger any actual open action

That points more to the click/action path than to path resolution alone.

One more useful distinction from testing:

The blue items that do not work also show nothing on hover.

So there seems to be a split between:

• real local file references, which get hover/tooltip behavior and can at least behave like a file control
• blue text that only looks like a link, but has no hover behavior and no open action

That suggests at least some of the failures are happening before the normal file-open control is even attached, not just during the final open step.

I can still reproduce this in the Windows Codex desktop app on a newer build.

Environment:

• App version: 26.313.5234.0
• OS: Microsoft Windows [Version 10.0.26100.8037]

In a real Codex Desktop workflow, assistant replies included absolute local file links to generated artifacts, for example:

[spec](E:/.../deck.spec.json)
[qa](E:/.../qa_report.json)

Observed behavior:

• clicking these local file links did not successfully open the target
• for code / JSON artifacts, the user reported that Codex opened a blank editor page instead of the actual file

Useful narrowing signal:

• the same files definitely existed and were readable
• serving the same artifact directory over local HTTP worked immediately:
• http://127.0.0.1:65166/deck.spec.json -> 200
• http://127.0.0.1:65166/qa_report.json -> 200
• http://127.0.0.1:65166/index.html -> 200

So this still looks like a Windows app local-file-link classification / open-path bug, not a file generation problem.

Expected behavior:

• clicking a local file reference should open the file
• if direct open is not possible, the app should at least reveal the file in Explorer
• if the path form is unsupported, it should not render as a seemingly-openable file link that results in no action / blank editor