PathUri misclassifies percent-encoded Windows drive URIs as POSIX

What version of Codex is running?

Source build from main at 312caf176a8fd3a5897a3d1fd3ed0a283bd1b5ac.

What subscription do you have?

N/A — direct source-level reproduction.

Which model were you using?

N/A — direct PathUri unit reproduction.

What platform is your computer?

Darwin 25.5.0 arm64 arm.

What terminal are you using?

VS Code integrated terminal.

What issue are you seeing?

PathUri classifies file:///c%3A/Users/Alice/src as POSIX even though decoding its first path segment produces the Windows drive c:.

• Observable sequence: parse the URI, then call infer_path_convention().
• Expected: Windows.
• Actual: Posix.

The classifier is intentionally host-independent: an existing test classifies a literal file:///C:/... URI as Windows on every host. That makes this reproducible on macOS without claiming a Windows application reproduction.

Actual screenshots

Before — upstream base plus the regression test only (macOS): the named test fails with left: Some(Posix) and right: Some(Windows).

!Before: percent-encoded Windows drive URI test fails

After — same environment and exact test with the focused patch: the named test passes.

!After: percent-encoded Windows drive URI test passes

What steps can reproduce the bug?

Add this regression test in codex-rs/utils/path-uri/src/tests.rs:

#[test]
fn percent_encoded_windows_drive_uri_is_inferred_as_windows() {
    let path = PathUri::parse("file:///c%3A/Users/Alice/src").expect("valid path URI");

    assert_eq!(path.infer_path_convention(), Some(PathConvention::Windows));
}

Run:

just test -p codex-utils-path-uri percent_encoded_windows_drive_uri_is_inferred_as_windows

What is the expected behavior?

The first URI path segment should be percent-decoded before checking for the <letter>: Windows-drive form.

Expected: Windows
Actual: Posix

Additional information

The root cause is that is_windows_drive_uri_segment checks the raw spelling returned by Url::path_segments(), so it sees c%3A instead of c:.

This also causes inferred_native_path_string() to choose POSIX spelling. On Windows, to_abs_path() can then reject the URI because the inferred convention does not match the native convention.

The prepared patch decodes the segment using the existing decode_uri_path helper before drive detection and adds the regression test. The full codex-utils-path-uri suite passes: 58 tests run, 58 passed.

Related Windows file-link reports include #14079 and #14483, but neither reports or patches this exact encoded-drive classification path.

---

I have a PR ready if issue accepted