[Windows] “Open in folder” falls back to C:\ for mapped-drive/UNC project files
Open 💬 2 comments Opened Aug 14, 2026 by lizdoddmba
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
In the Windows Codex desktop app, Open in folder fails for a file in a project saved using a mapped network drive. The file preview works, but File Explorer opens at C:\ instead of the containing folder.
Environment
- Codex Windows app package:
26.810.4967.0 - Windows-native agent
- Local non-Git project
- Project saved as
X:\workspace, whereX:maps to a UNC network share
Steps to reproduce
- Open a local project saved through a mapped network drive.
- Open a generated or edited file in Codex’s file preview.
- Choose Open → Open in folder.
Actual behavior
File Explorer opens at C:\ and does not navigate to or select the file.
Expected behavior
File Explorer opens the file’s containing folder and selects the file.
Diagnostics
- The saved project path remains the mapped-drive path.
- Both the mapped-drive and UNC forms exist and are accessible.
- Running Explorer directly with the mapped-drive file path works.
- The preview displays the file successfully.
- Based on these observations, Codex may be normalizing the preview path to UNC before invoking Explorer; this is an inference rather than a confirmed root cause.
Privacy note
The affected project contains confidential enterprise data, so no session transcript, screenshot, identifying file path, or logs are attached. A sanitized reproduction can be provided if requested.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Issue #37525 appears related at the Windows path-normalization level, but this reproduction differs: #37525 uses a local SUBST/DOS-device mapping and reports malformed paths, file-browser failures, and crashes. This issue uses a mapped network drive backed by a UNC share and specifically reproduces Open in folder falling back to
C:\, while the Codex preview and a direct Explorer invocation both succeed. I’m keeping this issue open to preserve the distinct reproduction unless maintainers confirm that it has the same root cause and should be consolidated.