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

What version of the Codex App are you using?

Windows Store package observed from the running process:

OpenAI.Codex_26.818.3698.0_x64__2p2nqsd0c76g0

Both the Windows Codex app and the ChatGPT mobile app are fully updated as of 2026-08-20.

What platform is your computer?

Windows x64.

What issue are you seeing?

Creating any new projectless Codex chat from Remote in the ChatGPT mobile app fails with a project-trust error:

Can't verify project trust for C:\Users\<user>\Documents\Codex\2026-08-20hello-3.
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.

This is systematic for every newly created Remote chat, not specific to one repository.

The displayed path is malformed: it omits the separator between the date directory and generated chat directory:

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

The generated hello-3 directory:

exists at the actual path;
is an empty projectless-chat folder;
is not a Git repository;
is not a symlink, junction, shortcut, or reparse point;
has normal read/write permissions;
can be opened directly in Codex.

Opening that folder on the desktop does not solve the systematic problem because the next new Remote chat creates a different generated projectless directory and fails the same way.

Local inspection also found:

Remote Control has persisted installation and environment IDs;
the Remote configuration migration is marked complete;
the parent Codex workspace is already trusted;
no stale saved-project registration exists for hello-3;
hello-3 is correctly absent from saved local projects because it is projectless;
filesystem read/write/cleanup succeeds.

This appears to be a Remote projectless-chat classification and Windows path-joining defect: a generated projectless workspace is treated as a repository requiring an individual trust decision, while its validation path is constructed without a directory separator.

What steps can reproduce the bug?

Run the current Codex desktop app on Windows.
Enable Remote Control.
In the current ChatGPT mobile app, connect to the Windows machine.
Start a brand-new projectless Codex chat from Remote.
Observe the project-trust failure for the automatically generated chat folder.
Inspect the reported path and notice the missing separator between the date directory and chat slug.
Start another new projectless Remote chat.
Observe the same failure for the newly generated directory.

Opening/trusting the previous generated folder does not prevent the next new Remote chat from failing.

What is the expected behavior?

A new projectless Remote chat should start without being treated as a Git repository requiring project trust.

The generated Windows path should be canonical and correctly joined:

C:\Users\<user>\Documents\Codex\YYYY-MM-DD\<chat-slug>

If a trust check is intentionally required, it should apply to the stable projectless workspace root rather than requiring a separate desktop action for every automatically generated chat folder.

Actual behavior

Every new projectless Remote chat is blocked by repository trust verification. The error references a nonexistent malformed path with a missing backslash. Read-only mode is the only reliable workaround.

Impact

Remote cannot create normal writable projectless chats on the affected Windows machine. The user must either accept read-only mode, pre-create each chat on the desktop, or repeatedly interact with automatically generated folders, which defeats Remote's purpose.

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

[Remote][Android to macOS] "No project" chat fails with project trust error #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) <#39855 (comment)> 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 <#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:

Connect Android Remote to the Windows host.
Start a new chat with No project selected.
Remote creates an empty directory under %USERPROFILE%\Documents\Codex\YYYY-MM-DD\<generated-slug>.
Before the thread starts, Android reports that project trust cannot be verified for that directory.
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 Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup #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

Redacted Android Remote trust-verification error

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.

android-remote-new-chat-success-26.908.40834.zip

Update 2026-09-15: fixed for me in Codex Desktop `26.908.40834`

Normal projectless New chat from Android Remote now works for me on this version. I used the normal New chat button, sent test, and received the reply on Android—not Voice creation and not another agent creating the thread.

The successful test was at 02:59 PDT / 09:59 UTC on September 15:

Desktop release: 26.908.40834, recorded in the host log for this exact attempt.
Backend/CLI: 0.154.0-alpha.6.2.
At 09:59:22.791921200Z, the app server accepted test with turn_trigger: "remote_android".
The turn completed at 09:59:47.098Z after 24,157 ms, and its response appeared on the phone.
The exact Android app version was not captured for this attempt; there is no contemporaneous Android logcat attachment.

This is one confirmed successful retest of my previously failing normal creation flow. I cannot say whether this was the first fixed release or whether it resolves every other reporter's setup. The earlier affected versions and reproduction evidence are preserved below.

Earlier reproduction (historical)

Redacted Android Remote trust-verification error on the earlier build

Previous result: persisted after upgrade and reproduced with a single-word prompt

Affected Codex Desktop builds now confirmed:

Previous affected build: 26.818.8289.0
Then-current running affected build: 26.820.9563.0
Then-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

Follow-up to my earlier reproduction report:

One more useful boundary and workaround: on the same two Windows hosts where the official ChatGPT Remote flow fails its project-trust check, I can still create new writable Codex tasks through Hearth Remote, an unofficial open-source client I maintain. This works from both its Windows client (on another computer) and phone PWA.

Hearth Remote uses a local supervised Codex app-server listener instead of the official paired Remote new-task flow. The task it creates are normal local Codex tasks. This suggests that the host filesystem, trust configuration, and underlying task-creation capability are healthy; the failure is specific to the official Remote project/trust preflight before dispatch.

For anyone blocked by this issue and comfortable testing a public alpha, the project is here: AletheiaVox/HearthRemote. It's Windows-only, requires Tailscale, is not affiliated with OpenAI, and depends on experimental app-server interfaces that might change.

my workaround is to just tell my dedicated debugger chat to make the new thread for me (i had sent screenshots of each failure, so it already knew the prompts)

i do have a skill i made to make sure the threads have the ability to do that even when computer use is not activated, but it might just work even without that

still annoying that you can't do it through the officially supported UI route, but, doing it via another chat that already exists is way less overhead

@ ESKehler

Yeah, that works. I mostly created that app because Codex doesn't natively support Windows-to-Windows remote access or accessing anything when the Codex desktop app isn't running. And then I discovered it also bypasses the Trust issue discussed here so I thought I'd package it as an easy installer for other people. Glad things are working out for you though!

Confirmed on a newer Windows package: OpenAI.Codex_26.825.5331.0_x64__2p2nqsd0c76g0 (2026-08-29).

On Android ChatGPT Remote, every mobile-created New chat fails — including No project and with plain text such as 123. Existing Remote Recents remain fully usable and accept follow-up prompts, so the host, pairing, and existing project files are healthy.

A full desktop-app restart and remote-service restart did not change the behavior. The target path changes for each new chat (for example <user>\Documents\Codex\2026-08-29\test-3), making per-folder trust impractical. This looks like a Remote new-thread regression rather than a user configuration issue.

Could the team confirm whether a fix is planned, and which desktop/mobile version will contain it?

Some mechanism detail from black-box testing on Windows. I think two separate defects are being conflated in this thread, and that explains why the workaround in #40002 fixes it for some people and not others.

There are two independent failures. Projectless chats hit both.

Case-sensitive trust lookup (Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup #40002). The remote trust check compares the mixed-case path against config.toml keys that the app itself wrote lowercased, so nothing matches.
No trust entry is ever written for a generated projectless workspace. On this machine the last entry the app wrote on its own was dated 2026-08-27; every projectless folder generated since has no entry at all, in any casing.

For an existing project, only (1) applies. There is a lowercase entry available to re-case, so the #40002 workaround fixes it. I can confirm that independently: adding an exact-case duplicate alongside the lowercase key immediately restored new Remote chats in a saved project.

For a projectless chat, (1) and (2) compose. There is no entry to re-case, so the #40002 workaround is not applicable on its own. I believe that is what one commenter above ran into when they applied it and stayed blocked. Both conditions have to be satisfied: an entry must exist for the generated directory, and it must be in the exact casing Remote displays. Supplying both makes projectless Remote chats work again.

Observations that may help whoever picks this up:

Trust lookup is exact-path, with no ancestor inheritance. Trusting the parent Documents\Codex has no effect. Configs that predate the regression contain separate entries for <dir>, <dir>\outputs and <dir>\work, which is consistent with that.
config/read re-reads config.toml from disk on every call. An entry added externally is visible to the already-running app-server immediately, with no restart of Codex Desktop or codex.exe. Tested against an isolated app-server: call config/read, append an entry to the file, call config/read again, and the new key is present in the second response.
The app-server's thread/start does not enforce trust. It succeeds against an untrusted cwd. The gate appears to be on the client side, after config/read, which matches the failure happening before thread creation.
Remote sessions do not honour the configured projectless workspace root. In the desktop bundle that value is only read when the host is local, and otherwise falls back to join(homedir, 'Documents', 'Codex'). So pointing that setting at an already-trusted directory cannot work around this from Remote.
Generated directory names come from the first few alphanumeric tokens of the first message, and on collision the code advances <slug>, <slug>-2, ... skipping any name whose directory already exists. So pre-creating and pre-trusting folders does not help; the app simply picks the next unused name.

Status with a local workaround in place: a small filesystem watcher that writes a trust entry, in both spellings, for each new directory under Documents\Codex as it appears restores normal service. Both projectless and in-project Remote chats have worked consistently since. Because trust entries do not require the path to exist, also pre-writing the collision names <slug>-2 .. <slug>-N makes a retry succeed even if the watcher loses the race against the trust check.

Environment: Windows 11 x64, Codex Desktop 26.825.x, codex-cli 0.150.0, official ChatGPT Android app.

This is all black-box observation, so please treat the internals as inference rather than confirmed fact. Happy to provide more detail if it would help.

Additional reproduction: projectless Voice thread is displayed as a different Project on Android Remote and then hangs indefinitely

I found a stronger reproduction that may connect the projectless trust failure with the stale/incorrect Project metadata reported in #41197.

Reproduction

From ChatGPT Android Remote, create a new Codex session using realtime Voice.
The resulting thread is actually created successfully on the Windows host.
Open the same thread in Codex Desktop on Windows.
Confirm that:
- the thread works normally on Desktop;
- it is still No project / projectless;
- its working directory remains the generated projectless Codex workspace.
Return to the same thread from Android Remote.

Android behavior

When Android first attempts to open the thread, the header initially shows the expected projectless state.

For example, one screenshot shows:

Thread title: 新しいリアルタイム音声チャット (New realtime voice chat)
Location/group: チャット (Chats)
Connected Windows host displayed normally

While the thread is still loading, the header then changes without any user action.

A second screenshot of the same failure state shows:

Thread title changed to: リモート (Remote)
Project/group changed to: タイムカード (Timecard), which is a completely different existing Project
The conversation remains stuck on loading placeholders indefinitely

I did not move or rename the thread.

Important control

I checked the same thread again on the Windows Codex Desktop host after Android displayed the different Project.

Desktop still showed the thread as No project / projectless.

It had not actually been moved into the Timecard Project.

This means the Project change shown on Android appears to be a Remote/mobile metadata or presentation change rather than an actual host-side reassignment of the thread.

Possible failure sequence

Actual host state:
thread.project = none
thread.cwd = generated projectless workspace

        ↓ Android Remote loads thread

Android Remote resolves incorrect/stale Project metadata

        ↓

Displayed state:
thread appears to belong to an unrelated existing Project

        ↓

Displayed Project / actual projectless cwd / trust metadata do not match

        ↓

Remote cannot finish loading the thread

This could explain why projectless Remote sessions fail even when the actual thread exists and works normally on the Windows host.

It may also explain why Voice appears to partially bypass the original new-thread failure: Voice can create the projectless thread, but opening that thread afterward through the normal Android Remote UI still encounters the Project-association mismatch.

Possible relationship to recent Project reassignment behavior

A related possibility is that the newer ability to move threads between No project and named Projects introduced separate states for:

sidebar/display Project placement;
actual thread working directory;
runtime Project association;
Remote Project projection.

Issue #40703 already demonstrates that visual Project placement and the actual runtime working directory can diverge.

If Android Remote is resolving the display-side Project association while the underlying thread remains projectless, that mismatch could be contributing to both the endless loading behavior and the trust-verification failures.

Related issues

Windows Remote: every new projectless chat fails trust verification with malformed path #39855 — projectless Android/Windows Remote trust failure
Android Remote fails to verify trusted Windows projects due to case-sensitive path lookup #40002 — Windows Project trust lookup / path casing
[Windows/Android Remote] Stale project list persists across two phones; new chats cannot be created #41197 — stale Windows Project inventory exposed to Android Remote
[ChatGPT Desktop][macOS][Voice] Voice launched from a Project becomes Projectless and loses its origin #40703 — visible Project placement can differ from actual runtime/projectless workspace

I have screenshots showing the Android header changing from the projectless Chats state to the unrelated Timecard Project while loading. I can upload them manually if useful.

The key observation is:

Android Remote shows the thread as belonging to another Project, while Windows Desktop simultaneously confirms that the same thread is still projectless.

I can confirm that this issue is still reproducible on a newer Windows Codex build.

Environment:

Windows 11 x64
OpenAI.Codex Windows Store package: 26.825.6671.0
Codex CLI: 0.151.0-alpha.7.2
ChatGPT mobile app connected through Codex Remote
Reproduced on September 1, 2026

Every new projectless Remote chat creates a different directory, for example:

C:\Users\<user>\Documents\Codex\2026-09-01\test-2
C:\Users\<user>\Documents\Codex\2026-09-01\test-3

Each attempt fails with the project-trust verification error. Trusting the parent directory or one generated child directory does not fix the next attempt because a new child directory is generated every time.

As a control test, Remote works correctly when I select an existing saved project: a message sent from the phone is received and answered successfully. This confirms that Remote pairing, networking, account access, and normal saved-project trust are working. Only writable projectless Remote chat creation fails.

The projectless root is a real physical directory, not a symlink, junction, shortcut, or reparse point. File-system access is normal, and the generated directories are empty and are not Git repositories.

Please prioritize a fix in the next Windows Codex update. The Remote trust check should not require a separate trust decision for every automatically generated projectless directory, and the Windows path should be joined and canonicalized correctly. A regression test for writable projectless chats started from Remote on Windows would also be appreciated.

Navigation Menu

Repository navigation

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

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Actual behavior

Impact

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

Update 2026-09-15: fixed for me in Codex Desktop `26.908.40834`

Earlier reproduction (historical)

Previous result: persisted after upgrade and reproduced with a single-word prompt

Additional reproduction: projectless Voice thread is displayed as a different Project on Android Remote and then hangs indefinitely

Reproduction

Android behavior

Important control

Possible failure sequence

Possible relationship to recent Project reassignment behavior

Related issues

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Actual behavior

Impact

Activity

github-actions commented on Aug 21, 2026

anjel2026 commented on Aug 25, 2026

searchadvert commented on Aug 25, 2026

bryanpettit80-cpu commented on Aug 26, 2026

FuriousBot1 commented on Aug 26, 2026

NightRa commented on Aug 26, 2026

ESKehler commented on Aug 27, 2026

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

ESKehler commented on Aug 27, 2026

Update 2026-09-15: fixed for me in Codex Desktop 26.908.40834

Earlier reproduction (historical)

Previous result: persisted after upgrade and reproduced with a single-word prompt

Richaaldo commented on Aug 27, 2026

AletheiaVox commented on Aug 27, 2026

deskcode85 commented on Aug 28, 2026

Ghiath-Najjar commented on Aug 28, 2026

AletheiaVox commented on Aug 28, 2026

ESKehler commented on Aug 28, 2026

AletheiaVox commented on Aug 29, 2026

sheikings-lgtm commented on Aug 29, 2026

DavidTheArchitect commented on Aug 29, 2026

anjel2026 commented on Aug 30, 2026

Additional reproduction: projectless Voice thread is displayed as a different Project on Android Remote and then hangs indefinitely

Reproduction

Android behavior

Important control

Possible failure sequence

Possible relationship to recent Project reassignment behavior

Related issues

llmeking commented on Sep 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Update 2026-09-15: fixed for me in Codex Desktop `26.908.40834`