Codex Desktop: Open in Explorer intermittently opens C:\ instead of the target folder on Windows

Summary

In Codex Desktop on Windows, the "open in Explorer" / folder-opening affordance intermittently opens Windows Explorer at C:\ instead of the intended file or folder location.

This is intermittent; I cannot provide a deterministic repro. However, the behavior is specific and recurring: Codex Desktop sometimes opens Explorer at C:\ instead of the requested target folder. It has worked correctly in some builds/periods and later regressed, which makes it look like a zombie regression rather than a one-off user navigation error.

Observed behavior

When using the UI affordance to open a generated local artifact or its containing folder, Explorer sometimes opens at:

C:\

instead of the intended project subfolder. The most recent instance happened while trying to open a generated evidence folder inside a Windows workspace.

Expected behavior

Explorer should open directly to the requested folder, or to the containing folder for the requested file.

For example, if the selected artifact is in a workspace subfolder such as:

<workspace>\bug-evidence

then Explorer should open that folder, not C:\.

Environment

• App: Codex Desktop
• OS: Windows
• Workspace type: OneDrive-backed user documents folder
• Path characteristics: spaces in path; cloud-synced Windows user directory
• Date observed: 2026-06-21

Why this matters

This breaks the handoff from Codex-generated local artifacts to user inspection. It is especially frustrating when Codex has created a file or evidence package and the user clicks the app's open-folder affordance expecting to inspect the output, but is instead dropped at the root of C:\ and has to manually navigate back to the workspace.

It also makes review of generated artifacts worse inside Codex itself: if the folder-opening affordance is unreliable, inline review becomes much more important than asking the user to jump through Explorer and manually navigate long Windows context menus.

Notes

I am not attaching a sophisticated repro log because the important signal is that this is intermittent across Codex Desktop updates rather than a stable one-off path error. It has behaved correctly at times and then regressed again.

Likely useful areas to inspect:

• Windows shell integration / Explorer launch handling
• path quoting / escaping
• paths containing spaces
• OneDrive-backed workspace paths
• file path versus folder path handling

Suggested labels

• bug
• windows
• desktop
• shell-integration