Windows: Codex launches tools with \\?\ namespace cwd, breaking pnpm/Node tooling

[Braden-sui]

Summary

On Windows, Codex desktop is sometimes launching shells/tools with the workspace cwd set to the raw namespace path form \\?\C:\... instead of a normal DOS path like C:\....

That breaks Node ecosystem tools. In my case it caused pnpm to fail immediately with:

ERROR EISDIR: illegal operation on a directory, lstat 'C:'

This appears to be a Codex cwd normalization bug, not a repo-specific problem.

Environment

• OS: Windows
• Shell: PowerShell
• Workspace path: C:\Users\brade\OneDrive\Desktop\vibecodr
• Codex desktop app

Repro

1. Open a workspace in Codex desktop such that the terminal/process cwd becomes \\?\C:\Users\brade\OneDrive\Desktop\vibecodr
2. In the terminal, run:
   • Get-Location
   • node -e "console.log(process.cwd())"
   • pnpm -v
3. Observe that PowerShell and Node report the cwd as the raw \\?\C:\... path.
4. Observe that pnpm fails with EISDIR: illegal operation on a directory, lstat 'C:'.

Verified Comparison

Using the same repo on the same machine:

• With cwd = \\?\C:\Users\brade\OneDrive\Desktop\vibecodr

  • node -e "console.log(process.cwd())" prints \\?\C:\Users\brade\OneDrive\Desktop\vibecodr
  • pnpm -v fails with EISDIR: illegal operation on a directory, lstat 'C:'

• With cwd = C:\Users\brade\OneDrive\Desktop\vibecodr

  • node -e "console.log(process.cwd())" prints C:\Users\brade\OneDrive\Desktop\vibecodr
  • pnpm -v works normally

Expected Behavior

Codex should normalize Windows workspace cwd values before passing them to spawned shells/tools/processes.

Tools should receive a normal DOS path such as:

C:\Users\brade\OneDrive\Desktop\vibecodr

not the raw namespace-prefixed form:

\\?\C:\Users\brade\OneDrive\Desktop\vibecodr

Actual Behavior

Codex sometimes launches the terminal/processes with the raw \\?\ namespace path as cwd, which breaks pnpm and likely other Node tooling.

Impact

This breaks a lot of Codex desktop workflows on Windows because many app features eventually shell out to Node-based tools.

Likely Root Cause

Codex is probably preserving a Windows namespace path from internal file APIs and passing it through unchanged as the cwd for child processes.

Workaround

Manually cd to the normal path:

Set-Location -LiteralPath 'C:\Users\brade\OneDrive\Desktop\vibecodr'

or reopen the workspace from the normal path instead of the \\?\... path.

[github-actions]

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

• Windows: shell commands run from C:\ while Codex UI shows project directory (relative paths break) (bug?) #13253
• VS Code extension: wrong working directory after automatic context compaction #13627
• CLI: resume/fork on WSL can restore lowercased cwd from SQLite-normalized path #13337

Powered by Codex Action

[Braden-sui]

Follow-up with a proven local workaround.

I was able to fix this locally by adding a PowerShell startup shim that detects a \\?\ filesystem cwd and immediately normalizes it back to a standard DOS path before running Node-based tools.

Example:

function ConvertFrom-WindowsNamespacePath {
    param([string]$Path)

    if ([string]::IsNullOrWhiteSpace($Path)) { return $null }
    if ($Path.StartsWith('\\?\UNC\')) { return '\\' + $Path.Substring(8) }
    if ($Path.StartsWith('\\?\')) { return $Path.Substring(4) }
    return $Path
}

$location = Get-Location
if ($location.Provider.Name -eq 'FileSystem') {
    $normalizedPath = ConvertFrom-WindowsNamespacePath $location.ProviderPath
    if ($normalizedPath -and $normalizedPath -ne $location.ProviderPath -and (Test-Path -LiteralPath $normalizedPath)) {
        Set-Location -LiteralPath $normalizedPath
    }
}

After doing that, a fresh PowerShell session launched from the bad cwd:

• \\?\C:\Users\brade\OneDrive\Desktop\vibecodr

immediately normalized to:

• C:\Users\brade\OneDrive\Desktop\vibecodr

and then:

• node -e "console.log(process.cwd())" reported the normal path
• pnpm -v worked normally

So the global fix seems to be: normalize Windows namespace paths before passing the workspace cwd to spawned shells/tools/processes. In other words, if Codex is holding \\?\C:\... internally for file APIs, it should strip that prefix (and convert \\?\UNC\server\share to \\server\share) at the child-process launch boundary.

That should avoid requiring any shell-specific workaround and fix the entire class of Node/pnpm failures on Windows.

[Braden-sui]

Additional scope: the local PowerShell workaround fixes terminal-launched tools, but it does not fix creating a new worktree inside the Codex app.

That strongly suggests there are at least two affected boundaries:

1. shell/tool process launch
2. internal app worktree creation / workspace management

The shell workaround only helps with (1) because it runs inside PowerShell after the app has already started the shell. Worktree creation appears to bypass that entirely and still uses the raw \\?\... path internally.

One more signal: my local C:\Users\brade\.codex\config.toml currently contains both of these project keys:

• C:\Users\brade\OneDrive\Desktop\vibecodr
• \\?\C:\Users\brade\OneDrive\Desktop\vibecodr

That looks like path normalization is leaking into project identity as well, not just child-process cwd.

Also, the public repo already has a Windows helper for this exact class of issue:

• codex-rs/core/src/path_utils.rs defines normalize_for_native_workdir(...)
• on Windows it uses dunce::simplified(...) to collapse verbatim paths like \\?\D:\... back to D:\...
• codex-rs/core/src/config/mod.rs already uses that helper when resolving cwd

So the likely global fix is broader than shell launch alone:

• normalize Windows namespace/verbatim paths before using them as workspace/project identity
• normalize before spawning child processes
• normalize before any git/worktree creation flow

If maintainers prefer, the shell/tool failure and the in-app worktree creation failure could be tracked separately, but they look like the same root normalization bug surfacing in two different codepaths.

[ofek]

I made a tracking issue for the root cause of these classes of bugs #10347