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

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

• #13253
• #13627
• #13337

Powered by Codex Action

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.

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.

I made a tracking issue for the root cause of these classes of bugs https://github.com/openai/codex/issues/10347

I think this may have been fixed by https://github.com/openai/codex/pull/19606.