Windows: trusted project entry using `\\?\` path is not recognized by project trust lookup

Open 💬 4 comments Opened Apr 24, 2026 by albert-zen

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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\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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#19128
#18253
#17540
#18483

Powered by Codex Action

albert-zen · 4 months ago

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:

a trusted project entry already exists in config.toml
but trust lookup does not recognize \\?\D:\... and d:\... as the same project
so project-local config / hooks / exec policies are incorrectly treated as disabled

So my current read is:

likely same family of Windows path canonicalization bugs
but different user-visible failure mode and probably a different lookup path in code

If it helps triage, I would treat this as a related issue rather than an exact duplicate.

Lucky-Light-Sun · 3 months ago

I have the same problem. Moreover, after checking all these mentioned issues, there is no solution to make automation feature in windows work!

julesLubrano · 1 month ago

Additional reproduction on Codex Desktop with a WSL-backed local runtime.

Environment:

Codex CLI/runtime: 0.144.4
Windows Desktop app configured to run Codex in WSL
Workspace stored on a Windows drive and accessed from WSL through /mnt/c

The user config already contained:

[projects."/mnt/c/Users/<windows-user>/Documents/Codex"]
trust_level = "trusted"

Codex Desktop nevertheless displayed this warning:

To load project-local config, hooks, and exec policies, add
/mnt/c/users/<windows-user>/documents/codex as a trusted project
in /mnt/c/Users/<windows-user>/.codex/config.toml.

Adding the second entry with the exact lowercase spelling requested by Desktop removes the trust mismatch:

[projects."/mnt/c/users/<windows-user>/documents/codex"]
trust_level = "trusted"

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.