Repository navigation
Windows: trusted project entry using \\?\ path is not recognized by project trust lookup #19281
Description
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
- Have a trusted project entry like this in
C:\Users\<user>\.codex\config.toml:
[projects.'\\?\D:\desktop\imcodex']
trust_level = "trusted"-
Start Codex app-server or a tool that launches it from
D:\desktop\imcodex. -
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\imcodexD:\desktop\imcodexd:\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.
Activity
github-actions commentedon Apr 24, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
albert-zen commentedon Apr 24, 2026
I reviewed the suggested duplicates (
#19128,#18253,#17540,#18483). They all look highly related at the Windows path-normalization / path-equivalence layer, but I do not think this report is a strict duplicate.Those issues are primarily about Desktop thread history / sidebar / timeline / project identity drifting because equivalent paths are treated as different workspaces.
This issue is narrower and hits a different symptom surface:
config.toml\\?\D:\...andd:\...as the same projectSo my current read is:
If it helps triage, I would treat this as a related issue rather than an exact duplicate.
Lucky-Light-Sun commentedon May 2, 2026
I have the same problem. Moreover, after checking all these mentioned issues, there is no solution to make automation feature in windows work!
julesLubrano commentedon Jul 14, 2026
Additional reproduction on Codex Desktop with a WSL-backed local runtime.
Environment:
0.144.4/mnt/cThe user config already contained:
Codex Desktop nevertheless displayed this warning:
Adding the second entry with the exact lowercase spelling requested by Desktop removes the trust mismatch:
Both paths resolve to the same Windows-backed directory.
This suggests that the project trust lookup case-normalization issue also affects WSL
/mnt/<drive>paths, not only native Windows extended-length paths.The expected behavior is for equivalent Windows-backed paths to share one trust decision without requiring duplicate case variants.