Codex Desktop on Windows drops the backslash before .codex when copying/opening local file paths

Open 💬 2 comments Opened Jun 16, 2026 by luoxiaofeng1029

What issue are you seeing?

In Codex Desktop on Windows, a local file path shown in the chat UI is correct, but the right-click actions produce an invalid path.

Correct path shown by Codex:

C:\Users\13852\.codex\automations\java\yangzhou_guoyangqi_baseline.md

After using the right-click copy action, the copied path becomes:

C:\Users\13852.codex\automations\java\yangzhou_guoyangqi_baseline.md

The backslash before .codex is dropped, so Windows interprets it as a different directory: C:\Users\13852.codex.

That folder does not exist.

The right-click "Open in File Explorer" action also fails, likely because the same malformed path is passed to Explorer.

Steps to reproduce

On Windows, create or reference a file under a dot-prefixed folder, for example:

C:\Users\<user>\.codex\automations\java\yangzhou_guoyangqi_baseline.md

Ask Codex Desktop to output a clickable Markdown file link to that path.
Right-click the rendered file link.
Use the copy path action.
Paste the copied path somewhere.
Try the "Open in File Explorer" action.

Expected behavior

The copied path should preserve the directory separator:

C:\Users\<user>\.codex\automations\java\yangzhou_guoyangqi_baseline.md

"Open in File Explorer" should open the correct file or containing folder.

Actual behavior

The copied path loses the backslash before .codex:

C:\Users\<user>.codex\automations\java\yangzhou_guoyangqi_baseline.md

This points to a non-existent folder, and "Open in File Explorer" fails.

Platform

Windows / Codex Desktop app.

Notes

This looks like a Windows local file link path normalization or escaping bug in the Codex Desktop right-click context menu actions.

Related existing issues appear to cover other Windows local path handling cases, but I did not find this exact separator-dropping behavior for a dot-prefixed path segment.

View original on GitHub ↗

2 Comments

maddavo · 25 days ago

I can reproduce a closely related variant in Codex Desktop on Windows.

In this case, the malformed path is already visible in the mouseover tooltip for an assistant-generated local-file link, before using any right-click action.

The intended target followed this pattern:

C:\Users\<user>\.codex\.chatgpt-projects\<project-id>\printer-PID-test.cfg

The mouseover target instead followed this pattern:

C:\Users\<user>.codex.chatgpt-projects\<project-id>\printer-PID-test.cfg

The separators before both dot-prefixed directory names were removed. Clicking the link opened the file-viewer tab, which reported “Could not open file.”

This specific reproduction used an assistant-generated Markdown link target containing native Windows backslashes. The behavior suggests the path is being corrupted during Markdown/link parsing or target construction, rather than only by the right-click “Copy path” or “Open in File Explorer” actions.

No screenshot attached because it contains unnecessary local path details.

Ch1ldr3n · 9 days ago

Additional reproduction on Codex Desktop for Windows build 26.814.5167.0 (2026-08-19).

Assistant-generated clickable links pointed to existing files under a path shaped like C:\Users\<user>\.codex\worktrees\<id>\<repo>\AGENTS.md and ...\docs\agents\triage-labels.md.
The rendered/opened target intermittently omitted the separator immediately before .codex, so the links failed even though both files existed at the intended paths.
Re-emitting the same absolute targets with forward slashes, e.g. C:/Users/<user>/.codex/..., worked.

A minimal CommonMark-style parser check also reproduces the transformation deterministically for a native-backslash Markdown target:

source: [file](C:\Users\example\.codex\worktrees\demo\AGENTS.md)
href:   C:%5CUsers%5Cexample.codex%5Cworktrees%5Cdemo%5CAGENTS.md

The same target written with forward slashes preserves /.codex/. This supports the earlier observation that the corruption occurs during Markdown/link-target parsing or construction: \. is interpreted as an escape before the desktop app tries to open the local file. Normalizing generated Windows file-link targets to forward slashes (or otherwise protecting path separators before Markdown parsing) appears to avoid the failure.