codex - 💡(How to fix) Fix Windows: trusted project entry using `\\?\` path is not recognized by project trust lookup [2 comments, 2 participants]

Summary

On Windows, Codex appears to treat a trusted project entry stored as an extended-length path (for example \\?\D:\desktop\imcodex) as different from the normalized path it later checks (d:\desktop\imcodex).

As a result, project-local trust-gated features are reported as disabled even though the project is already marked trusted in C:\Users\<user>\.codex\config.toml.

Environment

• OS: Windows
• Observed on: April 24, 2026
• Codex CLI: 0.124.0

Repro

1. Have a trusted project entry like this in C:\Users\<user>\.codex\config.toml:

[projects.'\\?\D:\desktop\imcodex']
trust_level = "trusted"

1. Start Codex app-server or a tool that launches it from D:\desktop\imcodex.

2. Observe startup warnings similar to:

Project-local config, hooks, and exec policies are disabled in the following folders until the project is trusted, but skills still load.
    1. D:\desktop\imcodex\.codex
       To load project-local config, hooks, and exec policies, add d:\desktop\imcodex as a trusted project in C:\Users\xmly\.codex\config.toml.

Actual behavior

Codex reports the project as untrusted and asks for a second trust entry using d:\desktop\imcodex, even though the project is already trusted via the \\?\D:\desktop\imcodex entry.

Expected behavior

On Windows, trust lookup should treat equivalent path forms as the same project, including at least:

• \\?\D:\desktop\imcodex
• D:\desktop\imcodex
• d:\desktop\imcodex

A previously trusted project should not require a duplicate entry just because one side uses an extended path prefix and the other does not.

Suspected area

This looks like project trust key normalization / lookup on Windows. The symptom suggests the stored config key and the runtime lookup key are no longer normalized to the same representation before comparison.

Why this matters

This makes trust state feel flaky on Windows and can cause confusing startup warnings for already-trusted projects, especially after trust-gating was expanded to cover project-local config, hooks, and exec policies.