Windows Remote: every new projectless chat fails trust verification with malformed path

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

• #39678

Powered by Codex Action

Additional reproducible distinction and workaround:

• Creating a new projectless session through the normal ChatGPT mobile Remote UI fails with the trust-verification error described here.
• Creating a new session through Codex Voice succeeds on the same connected Windows machine.
• Sessions created through Codex Voice are writable afterward.
• Existing/past sessions also remain writable.

This suggests the Voice creation flow may use a different session/workspace initialization path that avoids the affected projectless-chat trust classification or malformed Windows path join. It is also a practical workaround while the normal Remote new-session flow is affected.

Voice is also broke. It broke the same time as chat. Chat now works since
there's been an update on mobile remote but voice on mobile still broken.

On Tue, Aug 25, 2026, 6:31 AM anjel2026 @.***> wrote:

anjel2026 left a comment (openai/codex#39855) <https://github.com/openai/codex/issues/39855#issuecomment-5411121075> Additional reproducible distinction and workaround: - Creating a new projectless session through the normal ChatGPT mobile Remote UI fails with the trust-verification error described here. - Creating a new session through Codex Voice succeeds on the same connected Windows machine. - Sessions created through Codex Voice are writable afterward. - Existing/past sessions also remain writable. This suggests the Voice creation flow may use a different session/workspace initialization path that avoids the affected projectless-chat trust classification or malformed Windows path join. It is also a practical workaround while the normal Remote new-session flow is affected. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/39855?email_source=notifications&email_token=BKTU5Q62J5GUBVU754VRYPL5LWIJTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBRGEYTEMJQG422M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5411121075>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BKTU5Q5H4JNYFI23ANG75235LWIJTAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TKMRRGA2DKMZZHE32C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BKTU5Q3EPB4RRA6WLPPPQTT5LWIJTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBRGEYTEMJQG422M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/BKTU5Q377ZXTIMY4C7A5MLL5LWIJTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBRGEYTEMJQG422M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>

I can reproduce this on Windows through Codex Remote from the ChatGPT Android app with No project selected.

One potentially important difference from the original report: in my case the path displayed in the trust error is correctly joined and points to the generated projectless directory structure, e.g.:

C:\Users\<user>\Documents\Codex\2026-08-25\what-is-this-new-trust-function

Remote still fails with:

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.

The mobile UI clearly shows No project selected when the failure occurs.

This suggests the malformed Windows path described in the original report may be a secondary symptom rather than the root cause. The underlying issue appears consistent with #39678: the automatically generated disposable/projectless workspace is being routed through repository trust validation as though it were a pre-existing project that should already have an explicit trust decision.

In other words, the trust failure can still occur even when Windows path joining is correct.

I have a screenshot of the failure with the correctly formed path and can provide additional version/environment details if useful.

I can reproduce this consistently on a Windows host controlled from the ChatGPT Android Remote UI.

Environment:

• Windows x64, build 26200.9168 (25H2)
• Codex Desktop package 26.820.7780.0
• codex-cli 0.145.0
• ChatGPT Android app (version not shown in the failure UI)

Steps / observed behavior:

1. Connect Android Remote to the Windows host.
2. Start a new chat with No project selected.
3. Remote creates an empty directory under %USERPROFILE%\Documents\Codex\YYYY-MM-DD\<generated-slug>.
4. Before the thread starts, Android reports that project trust cannot be verified for that directory.
5. The generated directory exists, is empty, and is not a Git repository.

A difference from the original report: in this reproduction, the displayed path contains the correct directory separators (...\YYYY-MM-DD\<slug>). The trust/classification failure therefore also occurs without the missing-backslash formatting defect.

Troubleshooting already attempted, with no change:

• fully quit and restarted Codex Desktop;
• removed and re-paired Remote Control;
• opened the generated folder and the actual repository in Desktop;
• verified the parent/project trust settings;
• selected an existing saved Git project;
• applied the exact-case Windows trust-entry workaround described in #40002;
• removed an unrelated empty invalid .git marker from the parent folder (retained as a backup).

Result: new writable Remote chats are still blocked by the same trust error. Read-only mode is the only remaining path, which does not allow normal product use.

This suggests the projectless workspace may be classified as a repository before initialization, independently of the Windows path-joining and path-casing issues. Redacted logs or thread identifiers can be provided through an OpenAI-controlled private channel if useful.

+1, this has been quite annoying and blocking my work, would be glad to see it fixed

<img width="853" height="1844" alt="Redacted Android Remote trust-verification error" src="https://github.com/user-attachments/assets/0860d988-df2f-484a-894b-a20cdaf264e9" />

Initial Windows/Android reproduction: generated workspace fails trust before thread dispatch

This began as one new-chat incident with retries. A later independent brand-new Remote chat reproduced the same failure again; see the follow-up comment below. Existing chats can still work, but every brand-new Remote chat attempt observed during the current test window has failed before dispatch.

Environment:

• Windows 10 x64
• Codex Desktop package 26.818.8289.0
• Remote client: official ChatGPT Android app
• Exact Android version not rechecked for this capture

I attempted to start one brand-new Remote chat. Android displayed:

Can't verify project trust for
C:\Users\<user>\Documents\Codex\<date>\<generated-slug>.

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.

The Windows path was correctly joined in this reproduction, confirming that the original missing-separator symptom is not required.

Three retries during the same incident created:

...\<date>\<generated-slug>
...\<date>\<generated-slug>-2
...\<date>\<generated-slug>-3

I checked the generated directories read-only. All three:

• exist;
• are empty;
• are not Git repositories;
• were created at the corresponding retry times.

Additional host-side boundary:

• no durable thread row exists for any of the generated working directories;
• no thread/start request was recorded in the exact failure window;
• the message never reached task dispatch or persistence.

Observed sequence:

Remote creates unique disposable directory
→ Remote performs trust check
→ trust check rejects the just-created non-repository directory
→ no thread/start
→ retry creates another suffixed empty directory

This makes the incident both a task-creation blocker and an orphan-directory leak. Read-only mode is not equivalent when the intended task requires normal writable or system-management capabilities.

Private host names, usernames, prompt-derived directory names, message contents, task IDs, and raw local paths are omitted.

<img width="841" height="1870" alt="Redacted Android Remote trust-verification error on the earlier build" src="https://github.com/user-attachments/assets/8257964f-c600-475e-95d3-6633bfcea5d2" />

Update: persists after upgrade and reproduces with a single-word prompt

Affected Codex Desktop builds now confirmed:

• Previous affected build: 26.818.8289.0
• Current running affected build: 26.820.9563.0
• Staged/pending build: 26.820.10647.0 — downloaded but not yet running or tested

The same failure reproduced on the current running build at approximately 20:00 local time. The complete new-chat prompt was simply:

test

Android again rejected the brand-new projectless Remote chat with the same trust-verification error and a correctly joined Windows path.

Host-side checks for this minimal reproduction:

• Remote created exactly one new prompt-derived directory at 19:59:56.
• The directory exists, is empty, and is not a Git repository.
• No durable thread row exists for that working directory.
• The message failed before task dispatch or persistence.

This confirms the defect survives the upgrade from 26.818.8289.0 to 26.820.9563.0; it is not specific to a complicated prompt or the earlier build.

Earlier on 2026-08-27, a separate brand-new projectless Remote chat also failed with the same error. Its generated directory was likewise empty and non-Git, with no durable thread row or host-side thread/start / turn/start entry in the corresponding failure window.

Every brand-new Remote chat attempt observed during these test windows has failed this way. I am not claiming that every future attempt must fail, but the behavior is repeatable across separate prompts, timestamps, and now two Codex Desktop versions.

The attached screenshot has the host name, username, absolute path, and prompt-derived folder redacted.

Confirmed on a Windows host with ChatGPT/Codex desktop app 26.820.60940 and ChatGPT Android Remote, both updated.

The failure persists on 2026-08-27:

• Every new projectless Remote chat is blocked before creation with the project-trust error.
• The generated path is under C:\Users\<user>\Documents\Codex\2026-08-26\<prompt-slug>-<n>.
• In this reproduction the displayed path includes the directory separator; nevertheless Remote still treats the generated empty projectless directory as a repository requiring a trust decision.
• Existing Remote threads resume normally.
• Creating a new task locally in the desktop app works normally.

So the issue is not limited to malformed path joining: even a correctly joined generated projectless path can fail the same trust check.

Additional reproduction with two independent Windows hosts and one mobile client.

Environment

• Host A: Windows x64, ChatGPT/Codex desktop MSIX 26.820.9563.0 after updating today
• Host A bundled CLI: codex-cli 0.150.0-alpha.8
• Host B: separate Windows PC, same ChatGPT account and same mobile Remote client
• Mobile ChatGPT app updated on 2026-08-27

Observed behavior

• Starting a new Remote task fails with the same project-trust error when selecting either No project or an existing saved project.
• The error still says to open the repository on the remote computer and select its original directory, including for No project.
• Existing tasks that were created on either desktop remain usable and writable from the phone.
• Creating a new task locally in the desktop app works normally; that task can then immediately be continued from the phone.
• The same boundary reproduces on both Windows computers.

Host-side trust check

• On Host A, the selected working folder is already explicitly recorded as trusted in config.toml.
• Its stable parent workspace and user-profile root are also recorded as trusted.
• Opening the folder locally and making the desktop trust choice therefore adds no missing state.

Troubleshooting attempted, with no change

• updated desktop and mobile apps;
• fully quit/restarted the desktop app;
• removed and re-paired Remote Control;
• opened/used the affected project locally;
• tested both an existing project and No project.

A separately installed CLI 0.150.1 also has no effect, as expected: the desktop Remote host continues to use its bundled CLI.

The cross-host result makes a single corrupt host trust database unlikely. It also suggests the failure is broader than projectless-workspace classification alone, because a saved and already-trusted project is rejected through the same mobile new-task flow.

Still broken for me. I created a new folder, reset both chatgpt apps on desktop and android, still the same error

Having the same issue since yesterday and it's very annoying