Windows app: in-app worktree creation still fails when workspace path normalization leaks \?\ paths #13847

Summary

On Windows, Codex app cannot reliably create a new worktree when the workspace/project identity has leaked into the raw namespace path form (\\?\C:\...).

This appears related to, but distinct from, the shell/tool cwd bug in #13845.

The terminal-side workaround for #13845 fixed pnpm/Node tooling in fresh PowerShell sessions, but it did not fix the app's built-in "create new worktree" flow. That suggests the app's internal worktree creation path is still using the raw namespace path internally.

Environment

• OS: Windows
• Codex desktop app
• Repo path: C:\Users\brade\OneDrive\Desktop\vibecodr

Repro

1. Open the repo in Codex desktop on Windows.
2. Hit the app flow to create a new worktree.
3. Observe that worktree creation still fails, even after applying a local PowerShell profile workaround that normalizes \\?\C:\... to C:\... for terminal sessions.

Important Observation

The PowerShell workaround only affects shells launched inside the app. It does not affect internal app codepaths.

That means:

• shell/tool execution can be worked around locally
• built-in worktree creation cannot

Likely Root Cause

The same Windows path normalization bug seems to be present at a deeper boundary than shell launch:

• workspace/project identity
• internal git/worktree creation flow
• possibly persisted project keys/config entries

For additional evidence, my local C:\Users\brade\.codex\config.toml currently contains both:

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

So path normalization appears to be inconsistent even before the shell boundary.

Public Repo Signal

The public repo already appears to have a helper for this class of problem:

• 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 normal drive-letter paths
• codex-rs/core/src/config/mod.rs already uses that helper for resolved cwd handling

That makes this look like a missing normalization step in the app/worktree codepath, not a fundamentally unknown Windows issue.

Expected Behavior

Creating a new worktree inside the app should work the same whether the underlying workspace was discovered from:

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

The app should normalize to the standard Windows path form before using the path for project identity or git/worktree operations.

Actual Behavior

The app still fails to create a new worktree, even after terminal sessions are locally normalized.

Relationship to Existing Issue

Related to #13845, but not fully fixed by the shell-launch workaround described there.

Workaround

Current workaround is external/manual only:

git -C C:\Users\brade\OneDrive\Desktop\vibecodr worktree add ..\vibecodr-mybranch -b mybranch

Then open the new worktree directly instead of relying on the in-app creation flow.