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

What version of the Codex App are you using (From “About Codex” dialog)?

26.305.950.0

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

On Windows, the Codex app appears to render local file links using a Unix-style path prefix, adding a leading slash before the drive letter, for example /C:/.... That path format is invalid for standard Windows file handling. As a result, when the app tries to open a file or folder from one of these rendered links, Windows returns an error and nothing opens.

In practice, this means the app is generating clickable links that look valid inside the UI but cannot be resolved correctly by Windows because the extra leading slash breaks the path. The result is that files and folders referenced in the app cannot be opened directly from those links.

Also. It's either I am blind (which could be the case) or there is no 'About' in Codex app for Windows, I pulled installed version number from Microsoft Store.

What steps can reproduce the bug?

Any prompt that asks to implement anything, in reference summary files will not open.

What is the expected behavior?

No response

Additional information

No response

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

Windows app file references resolve to invalid c:\\C:\\ path and fail to open #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:

drive-letter absolute paths are not being recognized as proper local file targets
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:

direct drive-letter paths in chat do not work reliably on Windows
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:

Windows app file references resolve to invalid c:\\C:\\ path and fail to open #13548: older Windows desktop symptom where local file references resolved to invalid c:\\C:\\... paths
[Desktop] Open in Finder fails for URL-encoded local paths (Chinese filenames) #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

@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:

local file links in the response were not clickable/openable from the app UI
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

Current Windows build still reproduces this exact `/C:/...` failure

I can reproduce this on the current Windows Codex Desktop package, and local retained logs show the defect also existed before the current package was installed.

Environment

Codex Desktop package: OpenAI.Codex 26.721.4979.0
App-server: 0.146.0-alpha.3.1
Package installed/staged successfully: July 24, 2026
OS: Microsoft Windows 11 Home 10.0.26200, 64-bit
Host: local

Reproduction

Open Codex Desktop on Windows in a local repository.
Have Codex provide a clickable reference to an existing local file, for example:

C:/Users/dougm/Documents/GitHub/EA/.planning/plans/AEOS-CONTENT-FACTORY-PLAN.md
Click or open the reference so Codex creates an open-file tab/watch.
Inspect the Codex Desktop log.

Actual behavior

The valid drive path is transformed to:

/C:/Users/dougm/Documents/GitHub/EA/.planning/plans/AEOS-CONTENT-FACTORY-PLAN.md

The app sends that value through fs/watch, which fails:

2026-07-27T16:30:32.025Z
method=fs/watch
errorCode=-32600

2026-07-27T16:30:32.043Z
Request failed
error={"code":-32600,"message":"Invalid request: AbsolutePathBuf deserialized without a base path"}
method=fs/watch
source=filesystem

2026-07-27T16:30:32.043Z
Failed to watch open file
errorMessage="Invalid request: AbsolutePathBuf deserialized without a base path"
hostId=local
path=/C:/Users/dougm/Documents/GitHub/EA/.planning/plans/AEOS-CONTENT-FACTORY-PLAN.md

This exact file produced the same failure ten times in the current log. Across retained local logs, there are 6,031 matching Failed to watch open file warnings between July 13 and July 27.

Packaged-code evidence

Read-only inspection of the current packaged renderer shows:

Both Windows drive forms are recognized by a pattern equivalent to ^[A-Za-z]:[\\/]. Therefore this is not caused by choosing forward slashes versus backslashes.
The shared resolver normalizes backslashes and then intentionally prefixes / to recognized drive-letter paths, mapping both C:/... and C:\\... to /C:/....
The open-file watcher calls that shared resolver and sends its result through fs/watch.
The app-server bridge forwards the watch parameters unchanged.
A separate packaged helper already strips the leading slash from /C:/..., but the watcher path does not apply it.
The native app-server rejects the malformed value through AbsolutePathBuf.

This is a producer/consumer path-contract mismatch in the shipped product, not a Markdown-formatting, file-permission, file-existence, or user-configuration problem.

Expected behavior

On a local Windows host:

C:/Users/... and C:\\Users\\... should normalize to the same valid native Windows path.
/C:/Users/... and file:///C:/Users/... should be converted to a valid drive-qualified path before filesystem RPC serialization.
fs/watch should receive a valid Windows absolute path.
The file should open and be watched reliably.
An already drive-qualified path must never receive another drive prefix.

Timing clarification

Although 26.721.4979.0 was installed July 24, the same /C:/... to AbsolutePathBuf failure appears in this machine's retained logs as early as July 13 under a 26.707 build. Therefore the July 24 update did not introduce the underlying defect. The current package does, however, still reproduce it.

Requested product fix

Please normalize paths once using the target host's filesystem rules before local filesystem RPC serialization. For Windows fs/watch and open-file operations, strip the synthetic leading slash or apply the existing native-path conversion before sending the request. The Rust AbsolutePathBuf validator should continue rejecting malformed paths; the producer should send a valid host-native path.

Please add regression coverage for:

C:/Users/...
C:\\Users\\...
/C:/Users/...
file:///C:/Users/...
spaces and Unicode path segments
UNC and WSL paths
duplicated-drive prevention such as C:\\C:\\...
open-file, reveal-in-Explorer, line references, and fs/watch

This issue was closed as completed on July 2, but the public record does not identify a linked PR, commit, milestone, release, or first fixed Desktop build. Please reopen this issue or identify the shipping fix and the Desktop package expected to contain it.

This is still broken for me. The /C:/ get transformed to file:///C:/ and open fine in the builtin browser but remains as /C:/ when selecting "Copy Path" from the right click menu. As a result I have to manually edit the path every time a paste it into another program.

Navigation Menu

Repository navigation

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

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

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

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

Current Windows build still reproduces this exact `/C:/...` failure

Environment

Reproduction

Actual behavior

Packaged-code evidence

Expected behavior

Timing clarification

Requested product fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using (From “About Codex” dialog)?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Mar 9, 2026

sunrisever commented on Mar 12, 2026

sunrisever commented on Mar 12, 2026

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

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

sunrisever commented on Mar 12, 2026

sunrisever commented on Mar 12, 2026

sunrisever commented on Mar 12, 2026

sunrisever commented on Mar 12, 2026

phillza commented on Mar 13, 2026

phillza commented on Mar 13, 2026

sunrisever commented on Mar 13, 2026

cz-bszy commented on Mar 13, 2026

phillza commented on Mar 17, 2026

phillza commented on Mar 17, 2026

phillza commented on Mar 17, 2026

Sapientropic commented on Mar 26, 2026

dougm1966 commented on Jul 27, 2026

Current Windows build still reproduces this exact /C:/... failure

Environment

Reproduction

Actual behavior

Packaged-code evidence

Expected behavior

Timing clarification

Requested product fix

LiteracyFanatic commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Current Windows build still reproduces this exact `/C:/...` failure