Skip to content

Codex Remote Can Resume Existing Threads but Cannot Start a New Chat: 'Can't Verify Project Trust'

What the evidence establishes

Remote connected and resumed existing threads successfully, while only new-chat creation stopped at project-trust verification. Issue #40002 reports the same failure stage, but the evidence does not establish that the Windows-plus-WSL observation has the same path-lookup cause.

Start pathCheck firstDo not infer
Existing threadWhether it continuesA general Remote outage
New chat in an existing projectDisplayed path versus stored trust keyCasing is also the WSL cause
“No project” or WorktreeRecord the generated displayed pathAdd a guessed trust entry
A task that needs no writesWhether Read only startsThat Read only permits writes

A diagnostic map separating Windows path casing, a missing separator, and WSL path aliases in Codex Remote trust failures

Existing threads worked while only new-chat creation failed

The observed configuration used the ChatGPT Android app, Codex Remote, Codex Desktop on Windows, WSL, Ubuntu, and a Git repository inside WSL. Windows referred to the repository through a UNC path like this:

\\wsl$\Ubuntu-26.04\home\<user>\<project>

Connecting from Android to the Windows PC and selecting the project succeeded. The phone could open and continue sessions that already existed on the PC. The failure occurred only when starting a new chat, before a thread was created.

Can't verify project trust. Open the repository in Codex on the remote computer and make a trust choice, then select that repository's original directory and try again. You can also start in Read only mode. If this continues, update Codex on the remote computer.

This is a first-hand observation from the stated environment, not a general Remote connection outage. It does not include server-side logs or an inspection of Codex's internal trust lookup, so a similar error message is not enough to assign the failure to one of the public issues.

Issue #40002 stops at the same externally visible boundary

openai/codex issue #40002 reports that an existing trusted Windows project could not start a new chat from Android Remote.1 Its GitHub API creation timestamp is August 21, 2026 at 20:05 UTC, which is August 22 at 05:05 JST.

The reporter's diagnostics say the Windows Remote connection was healthy, config/read succeeded, and existing threads resumed through thread/resume. When the trust check failed, Remote did not send the thread/start request that would create a new thread.

Step reported in #40002Result
Connect to the Windows hostSuccess
Initial config/readSuccess
Existing-thread thread/resumeSuccess
config/read immediately before the errorSuccess
New-chat trust checkFailure
thread/startNot sent

Issue #40002 reports successful config/read and thread/resume, followed by no thread/start after the failed trust check. The current observation matches only the externally visible boundary—existing sessions work while new-chat creation stops—because no internal request trace was observed in the current environment.

The direct condition reproduced in issue #40002 is Windows path casing.

In the report, Codex had stored a lowercase project path.

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

Android Remote requested the same Windows location using mixed case.

C:\Users\<user>\Example-Project

Windows normally resolves both forms to the same location. The reporter says that adding a trust entry whose casing exactly matched the path displayed by Remote allowed the new chat to start. Another user reported the same failure and workaround on a different project.2

That result is consistent with a case-sensitive key lookup. It remains a reporter diagnosis and workaround, not a maintainer-confirmed root cause or permanent fix.

Issue #39855 reports a missing separator in a generated path

Issue #39855 concerns a different flow: creating a new projectless Remote chat on Windows.3 The trust error displayed a nonexistent path without the separator between the date directory and chat slug.

Displayed: C:\Users\<user>\Documents\Codex\2026-08-20hello-3
Actual:    C:\Users\<user>\Documents\Codex\2026-08-20\hello-3

The reporter says that the actual directory existed, was empty, and was neither a Git repository nor a reparse point. Opening the previous generated directory on the desktop did not prevent the next new chat from generating another directory and failing again.

This issue concerns classification and path construction for an automatically generated projectless chat, rather than an existing trusted project. It reaches the same trust-error surface as issue #40002 under different conditions.

Issue #39678 extends to “No project” and Worktree on macOS

Issue #39678 reports that Android-to-macOS Remote failed project-trust verification when starting a new chat with “No project” selected.4 An existing trusted project worked in the same environment. The reporter described a possible “trust-routing regression”: Remote immediately validates the disposable directory created by the projectless flow as though it were a pre-existing local repository with an explicit trust decision, so validation fails before projectless-chat initialization can persist trust.

A separate user commented that Worktree mode also failed for existing trusted Git projects.5 Remote checked the trust of a generated worktree target before creation completed; the target did not remain on disk after the failure, and trusting the original repository did not resolve it.

This evidence shows that the error class is not limited to Windows or path casing. It does not prove that “No project,” Worktree, and existing-project flows share one implementation defect.

WSL exposes one repository through several path forms

The same WSL repository can be represented in at least these forms.

/home/<user>/<project>
\\wsl$\Ubuntu-26.04\home\<user>\<project>
\\wsl.localhost\Ubuntu-26.04\home\<user>\<project>

Issue #40002 directly tests casing differences in an ordinary Windows path. The three public issues do not show how Codex Remote normalizes Linux, wsl$, and wsl.localhost forms or which string becomes the trust key.

“A WSL UNC alias caused this failure” is therefore an unverified hypothesis. The observation establishes only that a new Android Remote chat selected an existing Git repository in WSL on a connected Windows host and then stopped at trust verification.

Diagnose the start mode and exact path before changing trust settings

Branch by start mode before changing any trust setting.

  1. The user records whether the failure occurred with an existing project, “No project,” or Worktree mode.
  2. An existing-project user compares the redacted Remote path with the stored trust key, checking drive letter, casing, and trailing separators.
  3. A “No project” or Worktree user records the generated displayed path and does not add a guessed trust entry.
  4. A WSL existing-project user records whether the project was opened through a Linux path, wsl$, or wsl.localhost, and which form Remote displayed.
  5. An existing-project user opens the original repository in Codex on the host, confirms its trust choice, and checks that Codex is current.
  6. The user tests Read only mode when the task does not require writes.

The exact-case entry from issue #40002 is a provisional workaround reported for ordinary Windows paths. Back up the configuration before editing it, and do not add guessed trust entries for paths Remote did not display. The public evidence does not establish that the same workaround fixes WSL paths.

A useful reproduction report includes the Android ChatGPT and Windows Codex versions, start mode, redacted displayed path, stored trust key, whether an existing thread resumes, and whether Read only mode starts. It should exclude usernames, private repository names, credentials, and the rest of the configuration.

All three issues remain open without a unified diagnosis

Issues #40002, #39855, and #39678 were open when checked on August 22, 2026. They share project-trust verification as a failure point, but cover an existing Windows project, a Windows projectless chat, and macOS projectless and Worktree flows.

The current operational decision is to branch by start mode and compare the displayed path with the stored trust key only for an existing project. The WSL root cause should remain unresolved until a matching reproduction or an OpenAI diagnosis is published.

Post this article Copy link

Sources

  1. openai/codex issue #40002, “Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup”, accessed August 22, 2026. It provides the existing-project trust keys, casing difference, reproduction, reported workaround, and open status. ↩

  2. Independent reproduction comment on issue #40002, accessed August 22, 2026. It reports the same failure and exact-case workaround on a separate project. ↩

  3. openai/codex issue #39855, “Windows Remote: every new projectless chat fails trust verification with malformed path”, accessed August 22, 2026. It provides the missing-separator path, projectless-chat conditions, reproduction, and open status. ↩

  4. openai/codex issue #39678, “[Remote][Android to macOS] ‘No project’ chat fails with project trust error”, accessed August 22, 2026. It provides the macOS “No project” reproduction, existing-project control, and open status. ↩

  5. Worktree-mode reproduction comment on issue #39678, accessed August 22, 2026. It reports a trust failure for a generated worktree path from an existing trusted project. ↩