Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.3698.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When starting a new Codex Remote chat from the ChatGPT Android app against a trusted project on a Windows host, Remote displays:

Can't verify project trust for C:\Users<user>\Codex-Orchestrator

The Windows host is connected normally and existing Remote threads can be resumed successfully. The failure occurs only when trying to start a new chat.

The project is already trusted in ~/.codex/config.toml, but the existing trust entry was stored using a lowercase Windows path:

[projects.'c:\users\<user>\codex-orchestrator']
trust_level = "trusted"

### What steps can reproduce the bug?

Android Remote attempts to open the project using the normal mixed-case Windows path:

C:\Users\<user>\Codex-Orchestrator

Adding a second trust entry whose casing exactly matches the path shown by Android immediately fixes the issue:

[projects.'C:\Users\<user>\Codex-Orchestrator']
trust_level = "trusted"

Both entries can coexist, and config/read returns them as separate keys.

I reproduced the same behavior with a second Windows project, so this is not project-specific.

Reproduction
Trust a local Windows project in Codex Desktop.

Confirm config.toml contains a lowercase trusted path such as:

[projects.'c:\users\<user>\example-project']
trust_level = "trusted"
Connect to the Windows PC using Codex Remote from the ChatGPT Android app.
Attempt to start a new Remote chat in that project.

Android displays:

Can't verify project trust for C:\Users\<user>\Example-Project

Add an additional exact-case trust entry:

[projects.'C:\Users\<user>\Example-Project']
trust_level = "trusted"
Retry New Chat from Android.
The chat now starts successfully.
Additional diagnostics

The failure occurs before thread creation.

During a failed attempt:

Android Remote connects successfully.
config/read succeeds.
Existing thread/resume requests succeed.
Android issues another config/read immediately before displaying the trust error.
No thread/start request is sent.

I also tested config/read using mixed-case, lowercase, uppercase, trailing-slash, drive-root, and omitted cwd values. Every request returned an equivalent configuration result containing the lowercase trusted project.

config/read does not return an effective trust result. It returns the config.projects map, so the caller must select the appropriate path entry.

A disposable configuration test confirmed that Windows paths differing only by case are preserved as separate keys by config/read.

This makes the behavior consistent with Android Remote performing a case-sensitive lookup similar to:

result.config.projects[requestedPath]?.trust_level

instead of normalizing/case-folding Windows paths before comparing them.

Workaround

Adding an exact-case duplicate entry to config.toml resolves the Android Remote failure immediately.

The workaround was reproduced successfully on two separate Windows projects.



### What is the expected behavior?

Windows project paths should be compared using Windows-appropriate case-insensitive path semantics when determining project trust.

For example, all of the following should resolve to the same trusted project:

C:\Users\<user>\Example-Project
c:\users\<user>\example-project
C:\USERS\<USER>\EXAMPLE-PROJECT

If a project is already trusted in `config.toml`, Android Remote should recognize that trust regardless of differences in path casing.

Starting a new Remote chat should proceed to `thread/start` without requiring a duplicate trust entry whose capitalization exactly matches the path presented to the mobile client.

### Additional information

Environment:

- Codex desktop app: 26.818.3698.0
- Active Codex CLI/app-server: 0.149.0-alpha.4
- Older fallback CLI also present: 0.130.0-alpha.5
- Host OS: Windows x64
- Remote client: ChatGPT Android app
- ChatGPT subscription: Plus

The Remote connection itself is healthy. Existing threads can be resumed from Android successfully. The failure occurs specifically when starting a new chat in an existing trusted Windows project.

During a failed attempt, Android successfully connects and issues `config/read`. No `thread/start` request follows the failed trust check.

Testing the installed app-server showed that `config/read` returns the same configuration regardless of whether `cwd` is mixed-case, lowercase, uppercase, has a trailing slash, points to the drive root, or is omitted.

The response contains the trusted project under the exact key casing stored in `config.toml`. `config/read` does not return a separate effective trust result, so the client appears responsible for locating the matching entry in `result.config.projects`.

A disposable configuration test confirmed that Codex preserves Windows paths that differ only by case as separate `config.projects` keys.

Verified workaround:

Adding a duplicate trust entry whose path casing exactly matches the path displayed by Android immediately resolves the problem.

For example:

[projects.'c:\users\<user>\example-project']
trust_level = "trusted"

[projects.'C:\Users\<user>\Example-Project']
trust_level = "trusted"

This workaround was reproduced successfully on two separate Windows projects.

Related issue #39855 also involves Windows Remote project-trust failures, but appears distinct: that report concerns projectless chats and a malformed generated path missing a directory separator. This report concerns existing saved/trusted projects and path casing during trust lookup.

<img width="1080" height="2520" alt="Image" src="https://github.com/user-attachments/assets/852f18fa-8d0e-45f1-a0ce-e3cbf8d50250" />

Start by tracing the config/read handling and the project-trust lookup that runs before thread/start. Compare the requested Windows project path with keys returned in config.projects, then verify that paths differing only by case resolve to the existing trusted entry and allow thread/start without a duplicate config.toml entry.