[Windows / Android Remote] No project tasks ignore configured D: workspace root and fail project-trust verification

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

Windows installed/running app package version: 26.903.8094.0 (verified from the running application's package path; the About dialog was not inspected).

Active Codex runtime observed locally: 0.153.4.

Android ChatGPT app version was not collected.

What subscription do you have?

Not collected for this report.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64.

Client: ChatGPT on Android, using Remote to connect to the Windows host.

What issue are you seeing?

The desktop app's Projectless task folder setting is set to D:\Codex, and desktop-created tasks use that drive. However, starting a new No project task from Android Remote creates its directory under the default C:\Users<user>\Documents\Codex location instead. The mobile task then fails with a project-trust verification error.

The saved host configuration was checked:

[desktop]
projectlessWorkspaceRoot = 'D:\Codex'

A desktop settings screenshot also shows D:\Codex for the projectless task folder.

The Android error, transcribed from the user's screenshot with the Windows username redacted:

Can't verify project trust for C:\Users\<user>\Documents\Codex\2026-09-09\new-chat-2. 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 prevents normal writable projectless work from being started on the phone and places newly generated folders on a drive different from the configured location.

What steps can reproduce the bug?

1. On the Windows desktop app, open Settings > General.
2. Change Projectless task folder to an existing directory on another drive, such as D:\Codex.
3. Start a projectless task on the desktop and observe that its workspace is under D:\Codex.
4. On Android, connect to that Windows host through ChatGPT Remote.
5. Start a new task with No project selected and submit a request.
6. Observe the default C: directory in the trust error instead of the configured D: root.

These steps describe the user's observed workflow. The mobile failure was supplied as a screenshot; the Android UI was not independently automated during the investigation.

What is the expected behavior?

New Remote projectless tasks should honor the connected host's configured projectless task folder. If Remote intentionally uses a different setting, that distinction and a supported way to configure it should be visible.

The generated workspace should follow the applicable trust policy without unexpectedly blocking every new projectless task on a desktop-side trust decision.

Changing the root is expected to affect new tasks; this report does not request automatic migration of existing tasks.

Additional information

Observed on September 9, 2026, around 23:48, UTC+8.

Local checks found:

• D:\Codex exists and multiple desktop task directories were created there earlier that evening.
• The unexpected C:\Users<user>\Documents\Codex\2026-09-09\new-chat-2 directory exists; its creation time was 23:48:40.
• The configured D: root is persisted in the host's config.toml, so this is not merely an unsaved settings field.
• The path in this screenshot includes the separator between the date and task name.

A read-only inspection of the installed desktop bundle found that createProjectlessThreadPaths passes no configured workspace root for host configurations classified as remote (including remote-control), while local creation reads projectlessWorkspaceRoot. The fallback is Documents/Codex under the home directory. This is a diagnostic lead, not proof that Android takes that exact code path.

It remains unconfirmed whether the directory mismatch causes the trust failure, whether both symptoms share a cause, and which component requires the fix.

Related reports:

• #39855: Windows Remote projectless trust failures, with a malformed-path symptom that is not present in this screenshot.
• #42920: Android Remote No project trust failures on Debian.
• #22875: original request for a configurable projectless workspace root; in this case the setting already exists and works locally, but the remote workflow does not appear to honor it.

Usernames have been redacted. No authentication data, raw session logs, or full configuration files are included.

Start at the createProjectlessThreadPaths entry point and the host configuration handling for projectlessWorkspaceRoot; compare local and remote-control behavior while reproducing with D:\Codex. Done means a new Android Remote No project task uses the configured root and passes the applicable trust verification.