[Codex Desktop Windows Bug] Path normalization error with SUBST mapped drive triggers frequent crashes (no issues on macOS)

Open 💬 2 comments Opened Aug 8, 2026 by lex1982103

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

When using the Windows version of Codex, I encounter frequent crashes. This issue does not occur on my Mac. I ran an analysis within Codex itself, and its findings are as follows:

We can confirm there is a bug related to path handling. More precisely, the Codex Windows desktop version has issues normalizing paths for drives created via the SUBST command. Local verification results: Drive X: is indeed mapped to D:\X using SUBST. Both D:\X\out\zy and X:\out\zy exist and point to the same project. However, Codex incorrectly concatenates the two path formats into: D:\X\out\zy\X:\out\zy This invalid path does not exist, and this error has appeared 777 times repeatedly in the logs to date. The path bug is confirmed. It likely increases the risk of crashes, though existing crash reports only confirm main process failures. We cannot conclusively prove that all four crashes were caused solely by this issue. The most reliable workaround for now: remove the X:\out\zy project from Codex’s sidebar, then re-add it using the physical path D:\X\out\zy. Do not have the same project listed simultaneously under both its physical path and mapped drive path. The OpenAI documentation does not list mapped drives as an officially documented limitation. It only recommends verifying working directories when path anomalies occur and submitting issues together with sessions and logs, per official troubleshooting documentation.

Since switching to using the actual physical directory, I have not experienced any further crashes.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 20 days ago

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

#36850
#36608

Powered by Codex Action

schnodo · 19 days ago

Independent confirmation, with an additional reproducible Workspace/Open file browser symptom.

Environment

Codex App: 26.803.5235.0
Bundled Codex CLI: 0.147.0-alpha.6.5
Subscription: Max 20x
Platform: Microsoft Windows NT 10.0.26200.0 x64
Persistent mapping originally created with PSubst3; it uses the standard Windows SUBST/DOS-device mechanism

Sanitized mapping and workspace

R:  -> D:\codex-subst
UI workspace root: R:\workspace\repo
Canonical/thread cwd: \\?\D:\codex-subst\workspace\repo

The Desktop UI/state retains the R:\... alias, while the thread database and native realpath use the backing D:\... path. The malformed combined path is not persisted; it is generated at runtime.

Opening Workspace → Open file leaves the tree empty and reports:

ENOENT: no such file or directory, stat
'D:\codex-subst\workspace\repo\R:\workspace\repo'

Desktop logs repeatedly contain the same composition in the watcher:

[git-init-watcher] Failed to watch workspace root for git init
cwd=D:\codex-subst\workspace\repo\R:\workspace\repo
errorCode=ENOENT

This reproduced across multiple repositories under the aliased drive, so it is not repository-specific. Git, the terminal, and agent filesystem access otherwise work.

The exact malformed path can be reconstructed with Node's Windows path behavior:

const path = require("path").win32;

const physical = "D:\\codex-subst\\workspace\\repo";
const alias = "R:\\workspace\\repo";

const relative = path.relative(physical, alias);
// "R:\\workspace\\repo" because the roots are on different drive letters

path.join(physical, relative);
// "D:\\codex-subst\\workspace\\repo\\R:\\workspace\\repo"

fs.realpathSync.native("R:\\workspace\\repo") returns the physical D:\... path, which explains how the app can end up holding both spellings.

Opening the repository using the physical path avoids the immediate browser failure, but it changes the persisted workspace identity and is not a general solution when the same Codex state is used on machines with different device-local backing paths.

This strongly supports a path-normalization bug where a drive-qualified result from resolving/relativizing different roots is later treated as a relative segment and joined to the canonical cwd.