Skip to content

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

Closed
Closed
Windows: Codex launches tools with \\?\ namespace cwd, breaking pnpm/Node tooling#13845
Labels
appIssues related to the Codex desktop appbugSomething isn't workingterminalIssues related to the in-app terminalwindows-osIssues related to Codex on Windows systems

Description

@BradenHartsell
BradenHartsell
opened on Mar 7, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    on Mar 7, 2026

  2. github-actions commented on Mar 7, 2026

    @github-actions
    github-actionsbot
    on Mar 7, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. BradenHartsell commented on Mar 7, 2026

    @BradenHartsell
    BradenHartsell
    on Mar 7, 2026
    Author

    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.

  4. BradenHartsell commented on Mar 7, 2026

    @BradenHartsell
    BradenHartsell
    on Mar 7, 2026
    Author

    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.

  5. ofek commented on Mar 8, 2026

    @ofek
    ofek
    on Mar 8, 2026

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

  6. bLightZP
    marked Bad initial terminal path #14350 as a duplicate of this issue on Mar 12, 2026
  7. ambrosino-oai
    added
    terminalIssues related to the in-app terminal
    on Apr 24, 2026

  8. charliemarsh-oai commented on Jun 22, 2026

    @charliemarsh-oai
    charliemarsh-oai
    on Jun 22, 2026
    Contributor

    I think this may have been fixed by #19606.

  9. linear
    closed this as completedon Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingterminalIssues related to the in-app terminalwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions