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

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.

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"

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.

@Turakam83

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.

Temporary Windows/Android Remote fix

Fully close Codex Desktop.
Open:

%USERPROFILE%\.codex\config.toml
Find and delete the lowercase entry for the affected repository:

[projects.'c:\users\<username>\documents\github\<repository>']
trust_level = "trusted"

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"

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.

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:

Start the new Remote chat with restricted / Read Only access.
Send a simple message such as Hello.
The thread starts successfully and Codex replies normally.
Change the same running thread to Full Access.
Send the actual task.
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:

Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup #40002 — Android Remote fails project trust lookup on Windows.
Windows Remote: every new projectless chat fails trust verification with malformed path #39855 — Windows Remote projectless chats fail trust verification.
Windows/Android Remote shows folder basename instead of the saved Desktop project name #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.

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

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: #39678 (comment)

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

Confirmed independently on Windows with Codex Desktop package 26.820.9563.0 (client 26.820.71523; app-server 0.150.0) and ChatGPT Android Remote.

The Remote connection succeeds, but creating a new chat fails after “creating the chat on the remote machine” with the localized error:

Impossible de vérifier la fiabilité du projet pour C:\Projects\…\schieber-jass

The saved desktop project path uses normal mixed casing, while the trusted entry in config.toml was all lowercase. Host diagnostics show the Android Remote client connects and performs config/read/filesystem reads, but no thread/start request follows the failed trust check.

Adding a duplicate trusted entry whose casing exactly matches the saved Windows project path makes both exact-case and lowercase keys resolve as trusted in a fresh app-server config/read. This further supports Windows path casing as the trust-lookup boundary.

No account identifiers, tokens, raw logs, or private repository content are included.

Independent confirmation on a newer Windows build: this remains reproducible with Codex Desktop 26.825.4187.0 and bundled Codex CLI/app-server 0.150.0-alpha.12.2.

Environment:

Host: Microsoft Windows NT 10.0.26200.0 x64
Windows build: 26200.9278
Remote client: ChatGPT for Android 1.2026.230 (32)
Repository: existing local Windows Git repository

Additional diagnostics:

The project saved by Codex Desktop uses the normal mixed-case path:

C:\Users\<user>\PhpstormProjects\<repository>
The corresponding trusted entry in the user configuration is stored in lowercase:

c:\users\<user>\phpstormprojects\<repository>
A direct config/read using the Desktop app's bundled runtime under the actual Windows account returns the lowercase entry with trust_level = "trusted".
The Desktop project registry identifies the mixed-case path as the saved local Git repository.
Desktop logs show Remote Control enabling successfully with no remoteControl/enable errors.
The user-facing project-trust rejection occurs before the requested Remote task starts.
No repository changes were required or attempted.
I did not alter config.toml or test the exact-case duplicate-entry workaround.

This supplies another reproduction on a newer Desktop/app-server release and is consistent with a case-sensitive lookup of the raw config.projects keys rather than Windows-appropriate path comparison.

I can confirm this issue on Windows with ChatGPT Android Remote.

Environment:

Codex Desktop: 26.825.4187.0
Bundled CLI/app-server: 0.150.0-alpha.12.2
Host: Windows x64

The issue affected all 16 saved local Windows projects on the host. Their existing trust entries used lowercase paths.

I added correctly-cased duplicate trust entries for all saved Windows projects while keeping the original lowercase entries. After updating config.toml, creating a new Full Access chat from Android worked successfully.

Unlike some reports above, I did not need to remove the lowercase entries. This suggests duplicate entries may behave differently depending on configuration or project state, even on the same Desktop build.

Confirming this independently on Codex Desktop 26.825.x / codex-cli 0.150.0 (Windows 11 x64, official ChatGPT Android app). A project that had been trusted for weeks failed with this error, and adding an exact-case duplicate entry alongside the existing lowercase one immediately restored new Remote chats. Both keys coexist fine.

Two details that may save others some time:

config/read re-reads config.toml from disk on every call, so the exact-case entry takes effect immediately. There is no need to restart Codex Desktop or codex.exe after editing the file. I verified this against an isolated app-server: config/read, append the entry, config/read again, and the new key is present in the second response.
This fix is necessary but not sufficient for projectless Remote chats (Windows Remote: every new projectless chat fails trust verification with malformed path #39855). Those generate a fresh workspace directory that currently receives no trust entry at all, in any casing, so there is nothing to re-case and this workaround alone does not unblock them. Both an entry for the generated directory and correct casing are required. I've written up the details in Windows Remote: every new projectless chat fails trust verification with malformed path #39855.

Adjacent workaround for the generated-Worktree-path variant

The exact-case config.toml workaround in this issue remains relevant to the
Windows path-casing failure. For the related failure where Android rejects a
fresh generated ~/.codex/worktrees/<id>/<repo> path, an exact trust entry is
not reusable because every attempt allocates a new ID.

I confirmed a host-side workaround on macOS with ChatGPT desktop
26.831.21537 and bundled Codex CLI/app-server 0.152.1:

Start an Android Remote task in Workspace for the saved Git project.
Ask that running task to create a separate task for the same saved
project through the native create_thread action, with
environment: { type: "worktree" } and only the user's self-contained task
as the new prompt.
Do not use fork_thread, which copies the parent conversation.
Open the created-task card on Android.

The host-created task bypassed the mobile preflight, produced a registered
detached worktree linked to the original repository, preserved a clean source
checkout, and contained no parent-chat history. The detailed cross-platform
trust-ordering discussion is in #39678.

Limitations: a pending clientThreadId is not a real threadId and should not
be used for pin/read/wait calls or retried blindly. The completed task can later
drop out of the normal list, so this is a task-start workaround rather than a
fix for trust routing or durable discovery.

No repository-specific identifiers or private source details are included here.

Additional confirmation with a Windows + Android Remote setup, with one extra detail involving Windows/WSL aliases for the same project.

I had the same repository trusted under both a native Windows path and a WSL /mnt/c/... path, for example:

[projects.'C:\\Users\\example\\OneDrive\\Projects\\MyProject']
trust_level = "trusted"

[projects."/mnt/c/Users/example/OneDrive/Projects/MyProject"]
trust_level = "trusted"

Codex Desktop on Windows could open the project normally, but creating a new Codex Remote chat from Android failed with a trust error that referenced the WSL-style path:

/mnt/c/Users/example/OneDrive/Projects/MyProject

I also tried keeping multiple Windows/WSL casing variants, but that did not help.

The workaround that fixed it was to remove every WSL /mnt/c/... trust entry for that repository and keep only one native Windows entry:

[projects.'C:\\Users\\example\\OneDrive\\Projects\\MyProject']
trust_level = "trusted"

After restarting Codex Desktop, creating a new Remote chat from Android worked immediately.

Other projects on the same machine were unaffected.

This looks related to the case-sensitive trust lookup already discussed here, but suggests another edge case: trust resolution may also become ambiguous when the same physical Windows directory is present in config.toml under both native Windows and WSL /mnt/c/... aliases. Normalizing Windows/WSL aliases before project trust evaluation may avoid this.

Confirmed this is still reproducible on Windows 10 with Codex Desktop 26.903.9818.0 (bundled CLI/app-server 0.153.4) and ChatGPT Android Remote.

Diagnostics:

Remote connected normally and existing threads could resume.
environment/info for the local environment returned cwd as file:///C:/Users//workspace/.
config/read returned the trusted project only under an all-lowercase key: c:\users<user>\workspace<repo>.
The local Codex CLI opened the same canonical mixed-case path without a trust prompt.
Android Remote failed before thread/start.

Workaround that resolved it:

Replace the lowercase trust table header with the exact path casing returned by environment/info:

[projects.'C:\Users<user>\workspace<repo>']
trust_level = "trusted"
Confirm config/read now returns that exact-cased key.
Restart Codex Desktop.

After that, Android Remote could start a new chat in the project. This confirms the case-sensitive Remote lookup is still present in desktop build 26.903.9818.0.

Confirmed: the exact-case, per-project trust-entry workaround works on my Windows host with Codex Remote from the ChatGPT Android app.

Existing chats opened successfully, but creating a new chat in an existing project failed with Can't verify project trust.
config.toml already contained a trusted parent directory, but it did not contain exact-case trust entries for the individual project directories.
We identified 38 existing project directories and added a separate [projects.'...'] entry with trust_level = "trusted" for each, preserving the exact casing of each Windows path.
After this change, creating a new chat from Android in the previously failing project succeeded.
All other sandbox and approval settings were left unchanged.

The additional detail in this case is that trusting the parent directory alone did not satisfy the Remote trust check; explicit entries for the individual projects with matching path casing resolved the observed failure.

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Temporary Windows/Android Remote fix

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

Environment

Behavior

Additional UI symptom

Control observations

Related issues

Adjacent workaround for the generated-Worktree-path variant

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Activity

unnamanama commented on Aug 22, 2026

Alex24500 commented on Aug 24, 2026

Turakam83 commented on Aug 25, 2026

robinschiro commented on Aug 25, 2026

Alex24500 commented on Aug 25, 2026

Temporary Windows/Android Remote fix

pabloskihub commented on Aug 27, 2026

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

Environment

Behavior

Additional UI symptom

Control observations

Related issues

Etoiline commented on Aug 27, 2026

evolsb commented on Aug 27, 2026

mlohri commented on Aug 28, 2026

sergeliatko commented on Aug 28, 2026

Tomodo1773 commented on Aug 29, 2026

DavidTheArchitect commented on Aug 29, 2026

wuseal commented on Sep 5, 2026

Adjacent workaround for the generated-Worktree-path variant

aferende commented on Sep 10, 2026

cbjjensen commented on Sep 10, 2026

Apartman36 commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions