File paths on Windows improperly treat their UNC representation as canonical

Context

As shown in https://github.com/rust-lang/rust/issues/42869, the choice to have std:fs:canonicalize return UNC paths is viewed as a mistake. The docs mention:

[...] it may be incompatible with other applications (if passed to the application on the command-line, or written to a file another application may read).

The word "may" is quite inaccurate though because in reality support for UNC paths is astonishingly rare, even for internal Windows APIs.

What issue are you seeing?

Codex appears to use these paths internally and leaks its usage, for example in how every project path in ~\.codex\config.toml is stored as UNC:

[projects.'\\?\C:\Users\ofek\Desktop\code\datadog-agent']
trust_level = "trusted"

[projects.'\\?\C:\Users\ofek\Desktop\code\hatch']
trust_level = "trusted"

[projects.'\\?\C:\Users\ofek\Desktop\code\msgspec']
trust_level = "trusted"

UNC paths should only ever be used internally, never exposed, to maintain interoperability with the vast majority of software and to reduce user confusion when seen.

Issues caused by UNC paths

• https://github.com/openai/codex/issues/6809
• https://github.com/openai/codex/issues/12350
• https://github.com/openai/codex/issues/13582
• https://github.com/openai/codex/issues/13618
• https://github.com/openai/codex/issues/13845
• https://github.com/openai/codex/issues/13846
• https://github.com/openai/codex/issues/13847
• https://github.com/openai/codex/issues/14182
• https://github.com/openai/codex/issues/14519
• https://github.com/openai/codex/issues/14703

Solution

One of the following two approaches must be chosen:

1. Keep UNC as the internal representation and strip the prefix upon external access. For example, when writing the paths to a file, during subprocess execution, or using Windows APIs that don't support UNC.
2. Change the internal representation to the one that is universally recognized and document how to enable a setting that would allow Codex to declare itself as long-path aware.

The former is the current approach that is obviously difficult to apply ubiquitously so I'd recommend the latter, which is the modern way offered by Microsoft (where possible). They recommend embedding an application manifest directly within the binary. This is pretty easy using something like the embed-manifest crate or manually setting the associated linker options.

The path normalization should likely use the normalize_for_native_workdir core utility, introduced in https://github.com/openai/codex/pull/13742, that relies on the de facto standard dunce crate.