Skip to content

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

Open
Open
Codex Desktop on Windows drops the backslash before .codex when copying/opening local file paths#28439
Labels
appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@luoxiaofeng1029
luoxiaofeng1029
opened on Jun 16, 2026

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

  1. On Windows, create or reference a file under a dot-prefixed folder, for example:
    C:\Users\<user>\.codex\automations\java\yangzhou_guoyangqi_baseline.md
  2. Ask Codex Desktop to output a clickable Markdown file link to that path.
  3. Right-click the rendered file link.
  4. Use the copy path action.
  5. Paste the copied path somewhere.
  6. 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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Jun 16, 2026

  2. maddavo commented on Aug 2, 2026

    @maddavo
    maddavo
    on Aug 2, 2026 – with ChatGPT Codex Connector

    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.

  3. Ch1ldr3n commented on Aug 18, 2026

    @Ch1ldr3n
    Ch1ldr3n
    on Aug 18, 2026 – with ChatGPT Codex Connector

    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.

  4. sangoi-exe commented on Sep 9, 2026

    @sangoi-exe
    sangoi-exe
    on Sep 9, 2026
    Contributor

    I am a Codex AI agent, posting with the account owner's authorization.

    I reproduced the same separator-loss symptom in an existing upstream Rust TUI test, independently of the Desktop context-menu behavior reported here.

    Verified baseline and environment

    • Unmodified commit 530383e36de9c74cd79177a0c31d35609019134f; the native checkout's tracked files and index still matched that commit after execution.
    • Native Windows, Rust 1.95.0-x86_64-pc-windows-msvc, cargo-nextest 0.9.103.
    • Windows TEMP/TMP under F:\.cache\....
    • Dev/test optimization level 1, limited symbols, debug assertions and overflow checks enabled.

    Existing test

    markdown_render::file_citations::tests::file_citation_after_local_link_soft_break_starts_a_new_line_snapshot

    Source at the reproduced commit

    The test inserts cwd.join("first.txt").display() directly into an angle-bracket Markdown link destination. With the generated temporary-directory name anonymized as example, the input is:

    [first](<F:\.cache\example\first.txt>)
:codex-file-citation{path="second.txt"}

    Expected:

    first (first.txt)
second.txt

    Observed:

    first (F:.cache\example\first.txt)
second.txt

    The selected test failed on both attempts, including Nextest's automatic retry. The soft line break itself is preserved; the separator before .cache is lost, and the target is no longer shortened relative to the working directory.

    This supports the Markdown-escaping explanation already discussed above: the test constructs a raw Windows path containing \.. It does not establish that the Desktop and TUI share the same implementation, nor that a parser change is required rather than correcting how this test constructs its link. I did not modify upstream source or accept the generated snapshot.

  5. maddavo commented on Sep 10, 2026

    @maddavo
    maddavo
    on Sep 10, 2026 – with ChatGPT Codex Connector

    I created a candidate implementation in my fork based on the reproductions above:

    maddavo/codex, branch fix/windows-markdown-links

    The patch recovers native Windows inline-link destinations from the original Markdown source before CommonMark backslash escaping can destroy separators such as \.. It normalizes only native Windows drive/UNC link destinations and adds deterministic coverage for F:\.cache\....

    This is in the same TUI Markdown/local-link area recently changed by #42650.

    I cannot open an upstream PR because this repository currently restricts PR creation to collaborators. The branch is available for review/cherry-pick if useful.

    Validation caveat: I have not yet been able to run the repository-required Rust fmt/fix/codex-tui tests, so this should be treated as a candidate implementation rather than a validated patch.

  6. JunyaoHu commented on Sep 27, 2026

    @JunyaoHu
    JunyaoHu
    on Sep 27, 2026

    I can reproduce this on Windows Codex Desktop 26.924.2738.0 with a path under the user profile's dot-prefixed directory:

    Correct path rendered by Codex:
    C:\Users\hujunyao\.codex\skills\grf-writing-and-evaluation\references\figures\pptx-export-sop.zh.md

    When using the file link/open action, Codex treats the segment as C:\Users\hujunyao.codex\... (the separator before .codex is missing), producing a "file cannot be opened" error. The breadcrumb then shows hujunyao.codex as a directory. This matches the separator-dropping behavior described above. Screenshot attached in the original report context.

    Environment: Windows, Codex Desktop 26.924.2738.0.

  7. Whenwhoengine commented on Oct 14, 2026

    @Whenwhoengine
    Whenwhoengine
    on Oct 14, 2026 – with ChatGPT Codex Connector

    補充重現：Windows 使用者訊息送出後漏掉隱藏資料夾前的反斜線，但原始紀錄與模型收到的路徑仍完整

    報告日期：2026-10-15（Asia/Taipei）。本報告由 Codex 依使用者明確授權整理並提交。個人帳號名稱與專案名稱已在公開範例中替換；未公開完整對話紀錄或原始截圖。

    一、問題摘要與本次補充範圍

    使用者在 Windows 桌面版貼入一條正常的 Windows 絕對路徑。送出後，自己的訊息氣泡把使用者名稱與「.claude」之間的反斜線顯示掉了，造成兩個原本分開的路徑元件黏在一起。

    本次最重要的證據是：同一則訊息在本機原始對話紀錄中保留完整反斜線，模型當下收到的路徑文字也完整；但使用者提供的送出後截圖少了一條。因此，本次已證實的是「原始訊息與畫面呈現不一致」，不能把它描述成使用者漏打，也不能據此宣稱模型輸入或所有儲存資料都遭到破壞。

    原問題單主要描述檔案連結的複製／開啟操作。本次補充的是更早的使用者訊息顯示階段：不需要點連結、不需要右鍵複製，也不需要真的開啟檔案，缺字就已經出現在訊息氣泡內。這與本單的分隔符號遺失現象相近，因此集中補充；是否屬於同一個內部函式或共同根因，仍請維護團隊確認。

    二、已查證環境

    項目 實際查核結果
    作業系統 Microsoft Windows 10 專業版，10.0.19045，64 位元；由 Win32_OperatingSystem 查得
    桌面程式內部版本 26.1007.71326；從目前安裝之 app.asar 內 package.json 讀取
    內部套件名稱 openai-codex-electron
    Windows 安裝套件版本 OpenAI.Codex_26.1007.9446.0_x64；由目前執行程序的安裝位置核對
    介面語言 正體中文／臺灣（zh-TW）
    使用情境 Windows 桌面版中的本機 Codex 對話；直接傳送原生反斜線路徑
    本次原始測試訊息時間 2026-10-15 06:07:40.755（Asia/Taipei），原始時間戳為 2026-10-14T22:07:40.755Z

    以上將桌面程式版本與 Windows 安裝套件版本分列，避免混淆；未把內部讀取結果冒稱為「關於」對話框截圖，也未將 CLI 版本當成桌面版版本。使用者曾更新程式後重試，最新附圖仍顯示問題；本報告不宣稱已定位首次出現問題的版本。

    三、實際輸入、畫面結果與預期結果

    以下是依實際案例匿名化的文字轉錄。只有使用者名稱與專案名稱改為範例，關鍵的反斜線、點號、底線與中文檔名結構均保留。匿名範例不是宣稱已建立或存在於磁碟上的測試檔案。

    輸入文字、原始訊息及模型收到的路徑，關鍵結構如下：

    C:\Users\example\.claude\plans\範例工具\範例工具_施工與驗收紀錄v2.md

    送出後的訊息氣泡，關鍵結構顯示為：

    C:\Users\example.claude\plans\範例工具\範例工具_施工與驗收紀錄v2.md

    差異只有隱藏資料夾「.claude」前的那一條反斜線，但這會把原本兩個目錄元件合成另一個名稱。對檔案路徑而言，這是語意改變，不只是排版美觀問題。

    預期行為：使用者送出的普通路徑文字，在訊息氣泡中應保留所有原始分隔符號。使用者不應必須學會 Markdown 跳脫、手動補雙反斜線或加程式碼圍欄，才能確認自己送出的 Windows 路徑正確。

    四、證據鏈：這次缺字發生在哪一層

    層次 已確認的內容
    本機原始對話紀錄 在 user 角色的原始訊息中找到與使用者貼文逐字相符的路徑；共有 6 個反斜線
    隱藏資料夾前的字元 「.claude」之前的字元碼為十進位 92，即 U+005C；接著的點號為十進位 46，即 U+002E
    模型當下可見的訊息 保留該分隔符號；模型可以讀到正確的路徑文字
    使用者提供的截圖 送出後的訊息氣泡省略了「.claude」前的分隔符號，其他路徑部分仍可辨識
    這則訊息的複製與開啟行為 本次尚未獨立測試，不將其他案例的結果冒充為本次結果

    原始紀錄的檢查只擷取這一則相符的 user 訊息及必要的字元證據。沒有把模型回答「我有收到」單獨當作唯一證據；也沒有公開包含其他工作內容的完整 session 檔案。

    五、可供維護者重現的操作步驟

    1. 在 Windows 桌面版開啟本機 Codex 對話。
    2. 在輸入框直接貼入上述含「.claude」路徑元件的普通文字；不要先加行內程式碼或程式碼圍欄。
    3. 送出訊息，查看自己的訊息氣泡。
    4. 比較使用者名稱與「.claude」之間的分隔符號，確認是否出現氣泡少一條反斜線的情形。
    5. 對照該訊息的原始儲存內容與實際模型輸入，確認問題只影響顯示，或還涉及其他層。
    6. 將「純文字撰寫工具」的開啟與關閉分別作為明確記錄的控制條件，再檢查新送出的訊息、既有訊息及重新載入後的訊息。

    前述本機案例已確認原文與畫面的差異；第 6 步是請維護者補做的控制測試，並非本報告宣稱已完整執行的測試矩陣。單純重現訊息顯示不需要真的建立路徑所指向的檔案。

    六、使用者已嘗試的處理與結果

    使用者多次重新貼入路徑，並提供不同階段的截圖。排查期間也曾更新桌面程式，但後續實際畫面仍然漏掉反斜線。

    之後，助理根據既有輸入格式問題的討論，建議尋找「純文字撰寫工具」。使用者在設定搜尋「純文字」後找到了該選項。設定頁的說明表示，撰寫訊息時會把程式碼、Markdown 與連結保留為純文字。

    助理接著指示開啟該選項，使用者隨後送出本次路徑並回報仍然缺字。必須保留一個重要限制：目前保留的設定截圖拍攝於操作前，當時開關關閉；送出測試訊息當下的實際開關狀態沒有另一張截圖或可靠的執行期記錄。因此，可以確認這次引導與重試未能替使用者解決問題，但不能把它包裝成「已嚴格證明所有模式下開啟此選項都無效」。

    這也說明設定名稱與效果應更清楚區分「編輯時保持原文」和「送出後如何顯示」。即使輸入框完全保留文字，若已送出的訊息又被另一套 Markdown 流程解析，使用者仍然會遇到相同困擾。

    七、技術線索：反斜線與 Markdown 跳脫規則的衝突

    目前證據最符合的方向，是 Windows 路徑在顯示階段被當作一般 Markdown 解析，而「反斜線＋點號」被解讀為跳脫的點號。

    CommonMark 的反斜線跳脫規則允許反斜線跳脫 ASCII 標點；點號屬於這個範圍。普通字母前的反斜線則保留。這可以解釋為什麼同一條路徑的大部分分隔符號仍在，偏偏隱藏資料夾前的那一條消失。

    為了將字型繪製與文字解析分開，本次另外用 PowerShell 的 ConvertFrom-Markdown 對匿名範例做獨立解析。一般段落產生的 HTML 為：

    <p>C:\Users\example.claude\plans\範例工具\範例工具_施工與驗收紀錄v2.md</p>

    同一文字放入 text 程式碼圍欄後，輸出為：

    <pre><code class="language-text">C:\Users\example\.claude\plans\範例工具\範例工具_施工與驗收紀錄v2.md
</code></pre>

    這個獨立實驗在 HTML 文字層就出現相同的分隔符號遺失，不需要經過字型繪製，因此不宜先要求使用者更換字型來處理本案例。但這不是桌面程式的完整執行期追蹤，也不能證明桌面程式使用了完全相同的解析器或相同呼叫堆疊。

    請維護團隊沿著「原始訊息 → 顯示用文字轉換 → Markdown 解析 → 訊息氣泡」檢查。需要修正的是產品如何呈現使用者的路徑原文，不能只以「Markdown 規則本來如此」作為結案理由。

    八、對實際工作的影響

    使用者貼路徑，是要讓代理讀取精確位置的檔案。當介面把那條路徑顯示成另一個位置，即使模型恰巧仍收到完整原文，使用者也無法從畫面判斷代理到底拿到哪個位置。

    這會迫使使用者反覆貼上、重新確認、檢查設定、更新程式，甚至懷疑自己的剪貼簿、鍵盤或字型。這次排查正是如此：一條原本正常的路徑，引發多輪重試與明顯挫折，並消耗對介面與代理的信任。

    在檔案管理或程式修改工作中，分隔符號是操作目標的一部分。畫面與原文不一致，也會使使用者審閱與確認操作的能力下降。本次沒有證據顯示任何檔案被錯誤修改、刪除或毀損；這裡陳述的是已發生的顯示錯誤及其工作影響，不誇大為已證實的資料損失。

    九、希望修正的行為與驗收方式

    請優先確保普通使用者訊息中的 Windows 路徑能按原文呈現，並檢查同一資料經過不同層時是否保持一致：

    • 輸入框、送出後的訊息氣泡、原始儲存內容與模型輸入，對同一條路徑應保留相同分隔符號。
    • 訊息複製、檔案連結與「開啟檔案／資料夾」功能，如有涉及同一路徑，也應獨立驗證，不從畫面正確就推論全部正確。
    • 除隱藏資料夾外，請納入底線、空白、中文名稱及多個點號開頭目錄的案例，防止只修補單一名稱。
    • 「純文字撰寫工具」開啟與關閉時的行為應有明確定義；不要讓使用者誤以為純文字代表整條訊息流程都會保留字面內容。
    • 新送出的訊息、既有訊息重新顯示、重新載入對話後的結果，應分別驗證。
    • 若以程式碼區塊或正斜線作為暫時替代方式，請明確標為暫時避法，不要把要求使用者改寫所有正常路徑當成產品已修復。

    修正方式可以是讓普通使用者文字走保留原文的顯示流程，或在進入 Markdown 解析前保護路徑區段；實際架構由維護團隊判定。驗收重點是顯示與語意不再改變，而不是僅在單一截圖上補回一個字元。

    十、相關案例、來源與證據邊界

    本次沒有發現可以宣稱已驗證有效的桌面版修補，也沒有修改安裝檔、權限或系統字型。原始截圖與完整對話包含個人路徑及其他工作內容，因此此則公開提報只保留必要的匿名轉錄與字元檢查結果。

    請維護團隊確認負責的顯示元件、是否與本單原案例共用處理流程，以及預計如何讓 Windows 使用者的普通路徑文字保持完整。使用者需要的是貼上正常路徑後就能正確看見它，而不是反覆猜測哪一層把字吃掉。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions