Skip to content

Windows app file references resolve to invalid c:\\C:\\ path and fail to open #13548

Closed
Closed
Windows app file references resolve to invalid c:\\C:\\ path and fail to open#13548
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcontextIssues related to context management (including compaction)windows-osIssues related to Codex on Windows systems

Description

@0okay
0okay
opened on Mar 5, 2026

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

26.304.1528.0 (from runtime path in logs: OpenAI.Codex_26.304.1528.0_x64)

What subscription do you have?

ChatGPT Plus (using Codex desktop app)

What platform is your computer?

Microsoft Windows NT 10.0.22621.0 x64

What issue are you seeing?

On Windows, clicking local file references generated in Codex responses can resolve to an invalid path with duplicated drive prefix, e.g.:

c:\C:\Users\Administrator\Documents\Playground\Claude-Patent-Creator\commands\create-patent.md

This fails to open and prevents reliable navigation from assistant responses to source files.

In addition, line-level focus behavior is inconsistent: users cannot reliably jump/focus to exact lines with collapsible context (diff-like experience) from response references.

Relevant log errors:

  • 无法读取文件 'c:\C:\Users\...\create-patent.md'
  • 无法解析不存在的文件 'c:\C:\Users\...\commands'

What steps can reproduce the bug?

  1. On Windows, use Codex desktop app in a workspace.
  2. Ask Codex to provide source references for local files/lines.
  3. Click a returned file reference from the response.
  4. Observe VS Code/Codex logs showing c:\C:\... and file open failure.

What is the expected behavior?

  1. Local Windows paths should resolve exactly once (e.g., C:\Users\...) when clicked.
  2. Clicking references should open the target file reliably.
  3. Line-level jump/focus should work consistently, with optional fold/collapse context similar to diff navigation.

Additional information

  • This appears to be App-side path normalization / URI-to-path conversion on Windows.
  • Separate warning also appeared in logs about settings.json BOM parse, but the path duplication issue reproduces as a distinct navigation problem.

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 Mar 5, 2026

  2. github-actions commented on Mar 5, 2026

    @github-actions
    github-actionsbot
    on Mar 5, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. ambrosino-oai
    added
    Context Mgmt
    on Mar 7, 2026
  4. etraut-openai
    added
    contextIssues related to context management (including compaction)
    and removed
    Context Mgmt
    on Mar 8, 2026
  5. ambrosino-oai
    added
    Context Mgmt
    on Mar 8, 2026
  6. ambrosino-oai
    added a sub-issue on Mar 9, 2026
  7. ambrosino-oai
    removed a sub-issue on Mar 9, 2026
  8. linear
    closed this as completedon Mar 10, 2026

  9. sunrisever commented on Mar 12, 2026

    @sunrisever
    sunrisever
    on Mar 12, 2026

    I believe the currently open Windows desktop app path-link bug in #14079 is closely related to this older issue.

    I reproduced a very similar family of failures on a newer Codex App build (26.306.996.0, Windows 10.0.26200.0 x64, ChatGPT Plus):

    • drive-letter absolute paths in chat such as <C:/...>, <D:/...>, <F:/...> render blue/underlined but are not treated as real local path objects
      • no path metadata
      • no Copy path
      • clicking does not open the file
    • </Users/...> works correctly and is treated as a real path object
    • <///C:/...> / <///D:/...> can still resolve incorrectly with an extra current-drive prefix (same family as the c:\\C:\\... symptom here)

    So although this issue is closed, the Windows desktop local-path normalization problem still appears to exist in current builds, and the active tracking issue seems to be #14079.

  10. sunrisever commented on Mar 12, 2026

    @sunrisever
    sunrisever
    on Mar 12, 2026

    For cross-reference, this older Windows desktop issue also appears related to:

    From current repros, #14079 looks like the broader active tracker, while this issue captures one specific Windows symptom (c:\\C:\\... invalid path resolution).

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 workingcontextIssues related to context management (including compaction)windows-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