›_ Codex Issues
Codex Issues / #40002

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

Open 💬 8 comments Opened Aug 21, 2026 by Clock0ut

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" />

View original on GitHub ↗

8 Comments

unnamanama · 6 days ago

Independent confirmation of the same failure mode on another Windows project.

Observed behavior:

  • The project was already trusted in ~/.codex/config.toml using an all-lowercase Windows path, e.g.:
[projects.'c:\users\<user>\documents\chatgpt\media explorer']
trust_level = "trusted"
  • Codex Desktop on the Windows host could open and use the project normally.
  • ChatGPT/Codex Remote on mobile failed to start a new chat and reported that it could not verify project trust for the mixed-case path:
C:\Users\<user>\Documents\ChatGPT\Media Explorer
  • Adding a second trust entry whose path casing exactly matched the path shown by Remote immediately fixed the problem:
[projects.'C:\Users\<user>\Documents\ChatGPT\Media Explorer']
trust_level = "trusted"

No Git/project changes were needed. This strongly suggests the Remote trust lookup is comparing Windows project-path keys case-sensitively instead of using Windows case-insensitive path semantics.

This is therefore reproducible independently and not specific to the project in the original report.

Alex24500 · 4 days ago

Confirmed on Windows with ChatGPT Android Remote.

Environment:

  • Codex Windows app: 26.818.5229.0
  • Bundled app-server: 0.149.0
  • Remote client identified in host logs as codex_chatgpt_android_remote
  • Repository: local Windows path

Symptoms:

  • Existing remote chats could be resumed.
  • New chats worked in Read only mode.
  • New chats failed in Full Access before thread creation with “Can't verify project trust.”
  • In one case, the error referenced a previously used repository even though a different repository was selected.

The trusted entries created by Codex Desktop were lowercase:

[projects.'c:\users\<user>\documents\github\reponame']
trust_level = "trusted"
Turakam83 · 2 days ago

I can confirm this issue on another Windows + Android setup, and I found an additional detail about the workaround.

Environment:

  • Windows host
  • ChatGPT Android app using Codex Remote
  • Codex Desktop app version: 26.818.61809
  • ChatGPT Plus

The symptoms were exactly the same:

  • Existing Codex threads could be resumed normally from Android.
  • New threads created on the Windows PC could then be resumed normally from Android.
  • Creating a new thread directly from Android failed with “Can't verify project trust”.
  • The issue affected all of my local projects, not just one repository.

My config.toml contained trusted project paths in lowercase, for example:

[projects.'c:\google drive\programme\etiquette']
trust_level = "trusted"

The actual Windows path shown/used by Remote is:

C:\Google Drive\Programme\Etiquette

I first tried adding a second exact-case entry while keeping the lowercase entry:

[projects.'c:\google drive\programme\etiquette']
trust_level = "trusted"

[projects.'C:\Google Drive\Programme\Etiquette']
trust_level = "trusted"

In my case, this did NOT fix the issue. Android spent a long time trying to create the new thread and eventually failed again.

I then removed the lowercase entry completely and kept ONLY the correctly-cased entry:

[projects.'C:\Google Drive\Programme\Etiquette']
trust_level = "trusted"

After restarting Codex Desktop, creating new Codex Remote threads from Android started working normally again.

I reproduced the same problem across multiple projects.

So in my case, the reliable workaround is not to keep duplicate case variants, but to make sure there is only one trusted project entry and that its casing exactly matches the Windows path used by Remote.

This strongly suggests that Windows project trust lookup is currently case-sensitive somewhere in the Remote flow, and that duplicate paths differing only by case may also interfere with project selection.

robinschiro · 2 days ago

Confirming that only @Turakam83 's solution worked for me as a workaround for creating remote threads from an Android device to a project hosted on Windows. I needed to add a correctly-cased entry AND delete the original lowercase-only entry to get this to work again.

Alex24500 · 2 days ago

Temporary Windows/Android Remote fix

  1. Fully close Codex Desktop.
  2. Open:

%USERPROFILE%\.codex\config.toml

  1. Find and delete the lowercase entry for the affected repository:
[projects.'c:\users\<username>\documents\github\<repository>']
trust_level = "trusted"
  1. Replace it with a single entry whose capitalization matches the path shown in the Android error exactly:
[projects.'C:\Users\<Username>\Documents\GitHub\<repository>']
trust_level = "trusted"
  1. Save config.toml, reopen Codex Desktop, and retry creating the Remote thread in Full Access.

Important: match the drive letter and every directory name character-for-character. Do not leave both the lowercase and correctly-cased entries—on some builds, duplicate case-equivalent entries still cause the trust check to fail.

The underlying bug appears to be that Android checks the raw config.projects keys case-sensitively, even though Windows paths are case-insensitive.

pabloskihub · 1 day ago

Additional reproduction: Read Only → Full Access works, direct Full Access fails

I can consistently reproduce what appears to be a related Remote trust/session initialization issue with ChatGPT Android connected to Codex Desktop on Windows.

Environment

  • Host: Windows x64
  • Codex Desktop: 26.820.71523
  • Remote client: ChatGPT Android
  • ChatGPT plan: Plus
  • Remote host connection itself is healthy

Behavior

Starting a new Remote chat with Full Access enabled from the beginning fails with the project trust verification error.

This happens both with newly created workspaces and with existing projects that are already usable normally in Codex Desktop.

However, I found a reliable workaround:

  1. Start the new Remote chat with restricted / Read Only access.
  2. Send a simple message such as Hello.
  3. The thread starts successfully and Codex replies normally.
  4. Change the same running thread to Full Access.
  5. Send the actual task.
  6. The thread now works normally with Full Access, including local command execution and connected integrations.

So the important distinction seems to be:

Full Access during thread creation → trust failure

but:

Read Only during thread creation → thread starts → switch to Full Access → works

This suggests the failure may be happening specifically during the initial Remote trust/session initialization before the thread is created, rather than being a real filesystem permission or Remote connectivity problem.

Additional UI symptom

There is another unusual behavior that started at the same time.

A Remote-created chat that would normally appear in Codex Desktop using its chat title is instead displayed in the Recent list using its generated local workspace path, for example:

C:\Users\<user>\Documents\Codex\2026-08-27\<generated-chat-folder>

The actual conversation itself works once it has been initialized through the Read Only workaround.

This makes me wonder whether the Remote thread is being incorrectly associated with the generated workspace path instead of its normal thread/project identity.

Control observations

  • Codex Desktop works normally locally.
  • The Remote Windows host is online and reachable.
  • Existing threads can run normally.
  • After the Read Only → Full Access transition, Full Access operations work.
  • Restarting Codex Desktop does not resolve the initial Full Access failure.
  • The issue is reproducible with more than one project.

Related issues

This may overlap with:

  • #40002 — Android Remote fails project trust lookup on Windows.
  • #39855 — Windows Remote projectless chats fail trust verification.
  • #36754 — Windows/Android Remote project identity/display-name mismatch.

The Read Only → Full Access workaround may provide an additional clue because it appears to bypass only the initial trust gate while leaving the resulting Full Access session fully functional.

I can provide additional screenshots or test a specific diagnostic sequence if useful.

Etoiline · 18 hours ago

Superseded by #41197, which contains the complete Windows/Android reproduction, the two-phone retest, the working Mac control, and the diagnostics.

evolsb · 17 hours ago

A macOS reproduction corroborates the broader raw exact-key preflight mechanism (separate from Windows case folding). On Android 1.2026.230, the original Git project is exactly trusted and present in host project/list, but a newly generated projectless/worktree execution path fails before thread/start. An exact trust write beginning only 0.326 ms after target birth still landed too late for the client decision. Host-created worktrees succeed.

Full redacted timing evidence: https://github.com/openai/codex/issues/39678#issuecomment-5443290360

This suggests the durable fix should use effective/server-side project identity (including linked-worktree source resolution) rather than a client lookup equivalent to config.projects[requestedPath].