[Remote][Android to macOS] "No project" chat fails with project trust error

What version of Codex CLI is running?

codex-cli 0.148.0-alpha.15 (bundled with ChatGPT desktop 26.814.41407, build 6720)

What subscription do you have?

ChatGPT subscription; exact tier is not shown in the Codex Remote failure UI

Which model were you using?

N/A — the task fails before a model starts

What platform is your computer?

Darwin 25.5.0 arm64 arm; macOS 26.5.2 (build 25F84)

What terminal emulator and version are you using (if applicable)?

N/A — reproduced through ChatGPT Android Codex Remote

Codex doctor report

What issue are you seeing?

Starting a Codex Remote chat from the Android ChatGPT app with No project selected consistently fails before the task starts.

The mobile app displays:

Can't verify project trust for /Users//Documents/Codex/2026-08-20-test-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.

The generated path exists on the connected Mac, but it is empty and is not a Git repository. Selecting an existing trusted local project on the same Mac works, so the Remote connection itself is healthy.

The issue reproduced twice with two separately generated projectless directories, including after fully restarting both the Android and macOS apps.

What steps can reproduce the bug?

Connect the Android ChatGPT app to a Mac through Codex Remote.
In Android, open New chat for the connected Mac.
Leave the project selector set to No project.
Enter a prompt and try to start the chat.
Observe that the chat does not start and a project-trust error appears.

Reproduction history:

13:22:05 UTC+5: generated 2026-08-20-new-chat-2 and failed.
14:43:57 UTC+5: after restarting both apps, generated 2026-08-20-test-2 and failed again.
Both directories were created at failure time, contain no files, and are not Git repositories.
Frequency: 2/2 attempts.
Control: selecting an existing trusted project succeeds.

Feedback thread ID: 01a01e93-b36b-7fc3-97f6-909b6c717257 (feedback recorded without logs).

What is the expected behavior?

A projectless Remote chat should start in its newly generated working directory without requiring that disposable directory to have been opened and trusted as an existing repository.

Additional information

This appears to be a trust-routing regression: the projectless flow creates a new disposable directory, but Remote immediately validates it as though it were a pre-existing local repository with an explicit trust decision. The validation fails before projectless-chat initialization can persist trust.

Environment:

Android ChatGPT app, Codex Remote (mobile version not shown on the failure screen)
ChatGPT desktop 26.814.41407, build 6720
Bundled Codex CLI 0.148.0-alpha.15
macOS 26.5.2, build 25F84
Connected Mac remained online
Restarting both apps did not help

Impact: all write-enabled projectless Remote chats are blocked. Existing trusted projects work; Read only mode is the only suggested projectless workaround.

Raw logs and screenshots are intentionally omitted because they contain unrelated private configuration, the local username, and computer name. The full error is transcribed above with PII redacted.

I can reproduce an adjacent, broader variant on Android Remote → macOS: starting a new task in Worktree mode fails for existing trusted Git projects.

Environment:

Codex Desktop: 26.818.32112 (build 6933)
Bundled codex-cli/app-server: 0.149.0-alpha.4.1
macOS host, ChatGPT Android Remote client
Current Android app and OS versions as of 2026-08-22

Reproduction:

Connect the Android app to the Mac through Codex Remote.
Select an existing Git project that is already trusted in Codex Desktop.
Select Worktree and start a new task.
Remote fails before the task starts with:

Can't verify project trust for /Users//.codex/worktrees//. Open the repository in Codex on the remote computer and make a trust choice, then select that repository's original directory and try again.
Retrying generates a different UUID and fails again.

Additional evidence:

Reproduces across multiple projects, so it is not repository-specific.
The original project paths are explicitly trusted in ~/.codex/config.toml.
Opening/trusting the original repository in Codex Desktop does not fix it.
The generated worktree directory does not remain on disk; creation appears to stop at the trust check.
Creating worktrees locally in Codex Desktop works, so Git/worktree creation on the host is healthy.
Restarting both devices/apps and removing/re-adding the Remote device did not fix it.

This looks like the same trust-routing ordering problem as the projectless case, but for Remote-created managed worktrees: the generated target path is checked for exact-path trust before the worktree exists and can be associated with its already trusted source repository.

Independent reproduction on Android Remote → macOS, still present on a newer host build as of 2026-08-23.

Environment:

Host: macOS 26.6.2 (25G83), Apple silicon
ChatGPT/Codex desktop: 26.818.41509 (build 6962)
Bundled codex-cli: 0.149.0-alpha.4.1
Client: ChatGPT Android app (exact mobile version not captured)

Observed behavior:

Connect the Android app to the Mac through Codex Remote.
Start a new Codex task with No project selected.
The task fails before starting with the same project-trust error for the generated projectless workspace.
Creating a projectless task locally in the desktop app on the same Mac succeeds.

This confirms the Android-to-macOS projectless trust failure remains reproducible on desktop 26.818.41509 / codex-cli 0.149.0-alpha.4.1.

lol. so much for remote. You cannot even start a chat from your phone using remote. Do you openAI vibe coders even bother to test any of these features? Can you at least ask AI to e2e this?

+1

It worked for one session by revoking the remote access from desktop app. Then it stopped working. lol.

Independent reproduction on Android Remote → Linux, with additional host-side trace evidence.

Environment:

Host: CachyOS Linux rolling release, x86_64
ChatGPT desktop package: 26.810.52044
Bundled codex-cli/app-server: 0.148.0-alpha.9
Client: current ChatGPT Android app
Reproduced across multiple Android devices

Behavior:

Start a new Remote task with No project selected.
Remote creates ~/Documents/Codex/2026-08-25-test, then fails with the same project-trust error.
Retrying creates ~/Documents/Codex/2026-08-25-test-2 and fails identically.
Both generated directories are empty, user-owned, non-symlink directories and are not Git repositories.
Both ~ and ~/Documents/Codex were already explicitly marked trusted in ~/.codex/config.toml.
Updating/restarting the Android and desktop apps did not help. A task created on desktop could still be continued remotely.

The live host app-server trace identifies the caller as codex_chatgpt_android_remote. Its request sequence is:

process/spawn runs a shell command that creates the unique YYYY-MM-DD-<prompt> directory.
Remote then issues config/read.
Trust verification rejects the newly generated directory because it has no exact trust entry; trust from the parent projectless root is not inherited.

As a diagnostic workaround, I installed a narrowly scoped watcher for new, user-owned YYYY-MM-DD-* directories directly under ~/Documents/Codex. It writes the exact generated path to the Codex project trust map. A probe was detected and trusted in 12 ms.

With that watcher active, the next brand-new projectless Remote task succeeded. Successful task ID: 01a03aff-acba-7a11-8126-b1be38cd109b.

This strongly supports a trust-routing/order regression: Remote creates a disposable projectless workspace, then validates it as though it were a pre-existing repository requiring an earlier explicit trust decision. The generated workspace should either be recorded as trusted during projectless initialization or excluded from the repository trust gate.

The watcher is only a local compatibility workaround, not a proposed long-term fix.

@Superfishintights

Confirming @Superfishintights’ diagnosis and workaround on Android Remote → Windows Desktop → WSL Ubuntu, using codex-cli/app-server 0.149.1.

Initial problem

Neither Remote mode worked:

Managed worktrees failed the exact-path trust check.
Projectless chats failed the same check.
Their respective source repository and projectless root were already explicitly trusted.

Workaround

After seeing the watcher approach above, I implemented a narrowly scoped Rust/inotify service.

I first adapted it for managed worktrees. A generated worktree is trusted only when its repository name matches an existing explicitly trusted Git checkout.

I then extended it to projectless chats. It accepts only new, user-owned, date-prefixed direct children of the explicitly trusted projectless root.

Results

Managed worktree chats now start successfully.
Projectless chats now start successfully.
Exact trust entries are recorded within single-digit milliseconds.
Atomic config.toml replacements are monitored so entries are restored if necessary.

This independently confirms the finding above: Remote creates the target and performs an exact-path trust check before that generated path has been recorded.

Credit to @Superfishintights for identifying and proving the watcher approach.

there is still problem with

Trusted repository: /Users/example/Projects/example-repo
Selected workspace: /Users/example/Projects/example-repo/apps/web

Then security checks used exact execution paths, while the UI and configuration exposed trust mostly at the repository/project level.

Independent Android Remote → macOS reproduction, still present on 2026-08-27 after a full mobile cache/data clear, desktop restart, and fresh re-pair.

Environment:

ChatGPT/Codex Desktop 26.820.60940 (build 7119)
bundled codex/app-server 0.150.0-alpha.8
ChatGPT Android 1.2026.230, Android 17

Host controls all pass: the Remote client grant is fresh, existing-thread resume/turn submission works, project/list returns the saved Git project, and the original repository path is exactly trusted.

A fresh projectless attempt gave unusually precise ordering evidence:

generated target directory birth: T+0
scoped helper submitted exact-path config/batchWrite: T+0.326 ms
config.toml mtime: T+1.862 ms
app-server reload trace completed: approximately T+2.555 ms
exact trust entry persisted and a fresh config/read returned trusted
no new thread was stored for that cwd and the client still showed the trust failure

This means an after-creation watcher is not deterministic on this build even when it begins within a third of a millisecond. The Android client appears to take its trust snapshot before/in parallel with target creation, or it does not re-read a successful host write before aborting.

Managed Worktree mode shows the same generated-UUID failure. By contrast, asking the host desktop API to create the same project worktree succeeds immediately, yielding a clean isolated linked worktree. So pairing, Git, host worktree creation, and source-project trust are healthy; the failure boundary is the Android new-task preflight before thread/start.

A robust fix likely needs the mobile flow to defer trust validation until target creation has resolved the linked source repository, or to retry/evaluate effective trust server-side instead of indexing the raw config.projects map by the generated execution path.

Android Remote → Windows reproduction
Revoking and reconfiguring access didnt work, clearing android data didn't work, moving worktrees to the local folder didnt work

Windows version just updated: Chat GPT 26.825.31414

Android remote -〉Can't verify project trust for /Users//Documents/Codex/2026-08-20-test-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 remote\sand box is a hot mess. With all the watcher patch, it can now start a chat if you prompt text only. However, if you start a conversation with a image and a prompt, the entire chat would be stuck at loading state forever. Also the sandbox block git commit and there is no way around that.

Still reproducible on a newer macOS host build, and this is now a complete blocker for creating writable Worktree tasks from Android Remote.

Environment:

ChatGPT/Codex Desktop: 26.825.51511 (build 7377)
Bundled codex-cli/app-server: 0.151.0-alpha.7.2
Host: macOS
Client: ChatGPT Android Remote

Exact reproduction:

Select an existing saved Git project whose original repository path is explicitly trusted in ~/.codex/config.toml.
Select Worktree and choose a writable/full-access permission profile.
Start the new chat.
Remote rejects the newly allocated ~/.codex/worktrees/<generated-UUID>/<repo> path with the same project-trust error before the task starts.
Retrying allocates a different UUID and fails again.

Controls:

The saved project points to the correct original repository root.
The original repository is explicitly trusted.
Creating a worktree task from Codex Desktop on the same host works.
Existing Remote threads remain usable.
The generated target never reaches normal host-side worktree creation or thread/start.

This is not a repository configuration problem and telling users to trust the original directory does not address it. The Remote preflight is checking the generated destination path before it exists and before it can be associated with the already trusted source repository.

This issue has multiple independent reproductions across macOS, Linux, and Windows, but it is still open with no assignee, milestone, maintainer acknowledgement, or linked fix. The regression makes the newly exposed Android Worktree selector unusable for its primary purpose. Please prioritize this, assign an owner, and publish which desktop/mobile build will contain the fix. At minimum, Remote should validate trust using the selected source project identity/root, not require an impossible exact trust decision for a fresh random UUID.

I can reproduce this on the same current macOS host build, and the failure is broader than “No project” or newly allocated Worktree paths: the Android Workspace option is also being routed to a managed worktree path instead of the saved project’s trusted original directory.

Environment:

ChatGPT/Codex Desktop: 26.825.51511 (build 7377)
Bundled Codex app-server: 0.151.0-alpha.7.2
Host: macOS 26.6.2 arm64
Client: ChatGPT Android Remote

Reproduction and controls:

No project: a new writable chat was rejected for /Users/<user>/Documents/Codex/<generated-chat-directory>.
Select the existing saved Git project Team. Its original root, /Users/<user>/Documents/ChatGPT/Team, is explicitly trusted in ~/.codex/config.toml.
Worktree: Remote rejected /Users/<user>/.codex/worktrees/<generated-worktree-id>/Team; that target did not exist at the time of rejection.
Workspace: Remote rejected /Users/<user>/.codex/worktrees/<existing-worktree-id>/Team instead of using the original Team root. This worktree exists, and git rev-parse --git-common-dir resolves to /Users/<user>/Documents/ChatGPT/Team/.git, but Remote still requires an exact trust entry for the worktree cwd.
Host logs for all attempts contain neither the rejected path nor thread/start, so the mobile preflight is failing before the Mac receives a task request.

All three writable new-chat routes currently fail:

No project → generated projectless directory
Worktree → newly generated worktree directory
Workspace → managed worktree cwd rather than the trusted original project root

Trusting a parent directory cannot solve this because trust is exact-path and the generated paths change. The Workspace result is especially useful evidence: selecting Workspace does not use the saved project’s original trusted root.

Expected:

No project should not be classified as an existing repository requiring trust.
Workspace should use the saved project’s trusted original directory.
Worktree should validate trust against the selected source project/repository identity before allocating a destination, or otherwise inherit the source project’s trust decision.

The host is online, existing Remote threads remain available, and the failure occurs before task creation.

Confirming this is still reproducible on a substantially newer macOS host build, and my case is not projectless: it blocks new managed Worktree tasks for an existing saved Git project.

Environment (2026-09-04):

ChatGPT/Codex Desktop: 26.901.22334 (build 7746)
Bundled Codex CLI/app-server: 0.153.0
Installed standalone Codex CLI: 0.153.2
Host: macOS 26.5.1, Apple silicon
Client: ChatGPT mobile Remote

Reproduction:

Select an existing saved Git project. The project list resolves it to the correct original repository root, and that exact root is explicitly trusted in ~/.codex/config.toml.
Select Worktree and submit a new task remotely.
Remote creates an empty ~/.codex/worktrees/<new-UUID> directory, then rejects the not-yet-created ~/.codex/worktrees/<new-UUID>/<repo> path with “Can't verify project trust”.
Retrying generates a different UUID and fails identically. I reproduced this across three consecutive attempts.

Controls and attempted remediation:

Existing Remote tasks continue normally.
Local desktop worktree creation succeeds.
The saved project points to the canonical repository, not a stale worktree.
Trusting the canonical repository, ~/.codex/worktrees, and the broader project parent does not help.
Trusting one generated destination exactly does not help because the next retry allocates another UUID.
Config parsing, authentication, app-server handshake, network reachability, Git, disk space, and Remote enrollment all pass host diagnostics.
Removing a duplicate background Remote connection attempt did not change the result.

This confirms the failure boundary is the mobile new-task preflight before normal worktree creation or thread/start. It appears to validate exact trust against the random destination before associating that destination with the already trusted source repository.

The issue title currently says “No project”, but the impact includes existing trusted projects in Worktree mode on current macOS builds. It may be worth broadening the title/triage accordingly.

Additional cross-platform scope: I also encounter the same inability to start new Remote sessions/worktrees when selecting a Windows Mini PC as the host. Existing sessions on that host can still be continued. The Windows desktop/CLI version and host-side trace have not yet been captured, so I am reporting that as a second affected host rather than claiming identical internal ordering without logs.

Independent reproduction on Android Remote → Linux, still present on the current 26.901 runtime.

Environment:

Host: Linux x86_64 (kernel 6.8.0-136-generic)
Codex Desktop runtime: 26.901.31953
Linux wrapper package: 2026.09.04.205513
Bundled Codex CLI/app-server: 0.153.1
Client: ChatGPT Android Remote

Reproduction:

Connect Android Remote to the Linux host.
Start New chat and leave No project selected.
Enter a prompt and submit.
Remote creates ~/Documents/Codex/2026-09-04-<prompt> but rejects it with “Can’t verify project trust”.
Dismissing the warning and submitting again reproduces it consistently.

Host-side verification:

The generated directory exists, is empty, user-owned, and is not a Git repository.
It is absent from both the saved projects/project_roots records and the threads table, confirming failure occurs before task persistence.
The host remains connected and visible to Android Remote.
The desktop app and app-server remain healthy; existing tasks are unaffected.
Selecting No project in the UI does not clear or bypass the rejected generated working directory.

Expected: a writable projectless Remote chat should initialize its generated directory without applying the exact-path trust requirement intended for an existing repository.

This confirms the issue remains present in Codex CLI/app-server 0.153.1, newer than the Linux 0.148.0-alpha.9 reproduction already reported above.

Feedback ID: 01a0995c-0da2-7b71-8cb4-f40f8c834293

I'm also seeing this. Also posted about it in the forum.

What version of the Codex App are you using?

Codex desktop: 26.825.51511 (build 7377)

Bundled codex-cli/app-server: 0.151.0-alpha.7.2

What platform is your computer?

macOS 26.5.2, Apple silicon (arm64)

What Remote client are you using?

ChatGPT mobile app: Android

Mobile app version: 1.2026.237 (16)

What issue are you seeing?

Creating a new Codex task through Remote fails for some existing Git projects with:

Can’t verify project trust for /Users/<user>/.codex/worktrees/<worktree-id>/<repo>. 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.

The failure occurs with both Workspace and Worktree selected in the Remote new-task screen. It also occurs when main is selected as the branch.

The path in the error is not the selected project’s original directory. It is the generated worktree used by the task that is currently open on the desktop host:

Selected/trusted project:
/Users/<user>/Documents/Code/<repo>

Path incorrectly checked by Remote:
/Users/<user>/.codex/worktrees/<active-worktree-id>/<repo>

After switching to a different desktop task backed by another generated worktree, the error changed from one worktree ID to the new active task’s worktree ID. For example:

First attempt:
.../.codex/worktrees/<worktree-id-A>/<repo>

Later attempt after the active task changed:
.../.codex/worktrees/<worktree-id-B>/<repo>

This suggests that Remote’s new-task trust preflight is inheriting the currently active task’s runtime cwd instead of using the project and environment selected in the new-task form.

Steps to reproduce

On a Mac, open an existing Git repository in Codex Desktop.
Explicitly trust the original repository.
Start or open a desktop task running in a Codex-generated worktree.
Connect to the Mac through Remote in the ChatGPT mobile app.
Start a new task and select the same saved project.
Select Workspace.
Select main if a branch selection is shown.
Attempt to start the task with write access.
Observe a project-trust error referencing the currently open desktop task’s generated worktree.
Repeat with Worktree selected and observe the same failure.
Open a different worktree-backed desktop task and retry.
Observe that the worktree ID in the error changes to the newly active task’s worktree ID.

Expected behavior

When Workspace is selected, Remote should validate and start the task in the selected project’s original trusted directory.

When Worktree is selected, Remote should resolve trust through the selected worktree’s original repository, then create or select the managed worktree.

The currently open desktop task’s cwd should not affect a separate new-task request.

Actual behavior

Both Workspace and Worktree modes validate the currently active task’s generated worktree path.

The selected project’s original trusted directory is ignored, and the new task does not start.

Additional diagnostics

The original repository has an exact trusted entry in ~/.codex/config.toml:

[projects."/Users/<user>/Documents/Code/<repo>"]
trust_level = "trusted"

The saved project record points to the original repository path.
The active task is associated with that saved project but has a runtime cwd under ~/.codex/worktrees/<id>/<repo>.
The generated worktree is a valid linked Git worktree sharing metadata with the original repository.
The issue reproduces in multiple repositories, although not every repository is affected.
Restarting Codex Desktop did not resolve it.
Removing and re-pairing the Remote device did not resolve it.
The desktop app is already on the latest available production build.
Pairing succeeds; the failure happens during new-task trust verification.

Suspected cause

Remote appears to perform the trust check against the active task’s runtime cwd, or an inherited working-directory field, rather than the project ID/root and environment selected in the new-task form.

Because generated worktree paths use changing IDs, trusting an individual generated path is not a durable workaround.

Confirmed host-side workaround for saved Git projects

I tested a workaround for the Android Remote → macOS managed Worktree
variant. It bypasses the Android new-task trust preflight by asking an already
running Workspace task to create a separate Worktree task through the host's
native task API.

Environment used for this test:

macOS host
ChatGPT desktop 26.831.21537
bundled Codex CLI/app-server 0.152.1
ChatGPT Android Remote; mobile version not captured

Steps:

From Android Remote, start a task for the saved Git project with
Workspace selected. This must be a project whose Workspace route still
starts successfully.

In that task, send a self-contained request such as:

Create a separate Codex task for this saved project in a fresh managed Git
worktree. Use only the task payload below as the new task's prompt. Do not
fork this conversation or copy its history.

<TASK>

The running host task resolves the saved project and calls its native
create_thread action once with the task payload and a project target whose
environment is worktree.
Open the created-task card from Android.

Observed result:

The host created ~/.codex/worktrees/<id>/<repo> successfully.
git worktree list --porcelain registered it as a detached worktree.
git rev-parse --git-common-dir resolved to the original repository's Git
directory.
The new task contained the supplied task only; it did not contain the parent
conversation. Using fork_thread instead copied the parent history, so a
fork is not equivalent.
The original checkout remained clean and unchanged with this direct-create
route.

There are two important limitations. Worktree setup commonly returns only a
pending clientThreadId; it must not be passed to APIs that require a real
threadId, and an uncertain create must not be retried because that can create
duplicates. Also, a completed agent-created task may later disappear from the
normal task list even after it was initially visible, so open the task card
while it is available. This workaround starts the isolated task, but it does
not fix durable mobile discovery or the underlying trust-routing bug.

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

Independent reproduction on ChatGPT mobile Remote → macOS, still present on 2026-09-07.

Environment:

Host: macOS 26.6.2 (25G83), Apple silicon
ChatGPT desktop: 26.901.22334 (build 7746)
Bundled codex-cli/app-server: 0.153.0
Mobile client: exact OS/app version was not captured

Observed behavior:

Start a new Remote chat without selecting an existing project.
Remote creates a generated path under <home>/Documents/Codex/2026-09-07-<prompt-slug>.
The task fails before starting with the same Can't verify project trust message shown in this issue.

Host-side checks immediately after the failure:

The generated directory exists and is empty.
It is a normal user-owned directory with mode drwxr-xr-x.
It is not a symlink and is not a Git repository (.git is absent).
The generated path is absent from the host's saved-project list.
The generated path has no exact entry in config.toml.
All 162 existing project trust entries on this host are trusted; none is untrusted.
Control: projectless directories successfully created from the desktop app do have exact trusted entries.
No thread was created for the failed generated directory.

This rules out an ordinary filesystem ownership/mode problem on this Mac and supports the ordering diagnosis already reported here: the Remote projectless flow creates its destination but reaches exact-path trust validation before projectless initialization records trust and starts the thread.

I have omitted the screenshot and raw logs because they expose the local username, host name, unrelated paths, and thread identifiers. Targeted redacted diagnostics can be provided if useful.

Additional reproduction: existing saved non-Git projects fail on Android, while desktop creation and remote continuation work

Observed on October 12, 2026 (UTC+8). This is an adjacent variant of the project-trust failure in this issue: an existing saved project in its original directory, rather than a newly generated projectless directory or managed Git worktree.

Environment

Host: Apple silicon Mac mini, macOS 27.0.1 (26A434).
ChatGPT/Codex desktop: 26.1007.30912 (build 20156).
Bundled Codex CLI: 0.162.0-alpha.17.2.
Remote client: ChatGPT Android 1.2026.279.
Android OS version: not captured.
Four saved local project folders; the desktop project-list API reports that these are not Git repositories.

Observed behavior and reproduction

Open an existing saved local project on the Mac. Creating a new conversation from the desktop works.
Connect to that Mac through Codex Remote in the Android app.
Open an existing conversation and send another message: this works.
Start a new conversation from Android using a saved project.
The first request fails with a project-trust error. Retrying does not resolve it.

The failure was reported across all four saved projects. The captured screenshot identifies the original saved project directory, not a generated worktree.

The Chinese UI states that it cannot verify whether the project is trusted, instructs the user to open the repository on the remote computer and make a trust choice, then select its original directory and retry. It also suggests Read only mode or updating the host app.

Host-side checks and confirmed workaround

For the project used in the controlled test:

The directory exists, and its resolved path matches the saved desktop project path.
Before the change, the user-level ~/.codex/config.toml contained no [projects...] tables or trust_level entries for any of the four projects.
After backing up the config, we added only an explicit trust record for the selected project (illustrative path below):

[projects."/Users/<user>/Projects/example"]
trust_level = "trusted"

Existing settings and permission controls were preserved; no broad filesystem permission change was made.
Immediately afterward, the user successfully started a new conversation in that project from Android.
The same entries were subsequently added for the other three folders, but their mobile results were not separately confirmed at reporting time.

This is a before/after confirmation for one existing saved project, not a claim that exact-path trust fixes every projectless/worktree variant in this thread.

Product behavior to investigate

The observable inconsistency is that a saved project can support desktop-created conversations and remote continuation while Android new-conversation creation requires a trust record that normal desktop use has not established.

The workaround supports a missing explicit trust record as the immediate cause in this case. It does not establish the precise mobile/server implementation or whether this shares the same internal cause as the generated-directory reports above.

Expected behavior: desktop and mobile should use consistent effective trust semantics. If an explicit trust decision is required, provide a clear, actionable confirmation flow and persist that decision for subsequent supported clients. Merely opening or using the project on desktop should not leave the user stuck following a recovery instruction that does not produce the required state.

Please preserve explicit user consent and existing sandbox restrictions; the request is for a consistent trust flow, not automatic trust of arbitrary directories.

Private paths, host names, screenshots, full configuration, and unrelated logs have been omitted.

Navigation Menu

Repository navigation

[Remote][Android to macOS] "No project" chat fails with project trust error #39678

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

What version of the Codex App are you using?

What platform is your computer?

What Remote client are you using?

What issue are you seeing?

Steps to reproduce

Expected behavior

Actual behavior

Additional diagnostics

Suspected cause

Confirmed host-side workaround for saved Git projects

Additional reproduction: existing saved non-Git projects fail on Android, while desktop creation and remote continuation work

Environment

Observed behavior and reproduction

Host-side checks and confirmed workaround

Product behavior to investigate

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Remote][Android to macOS] "No project" chat fails with project trust error #39678

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

Codex doctor report

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

jMerta commented on Aug 21, 2026

iamhectorlopez commented on Aug 23, 2026

sdjg113 commented on Aug 24, 2026

wuseal commented on Aug 26, 2026

sdjg113 commented on Aug 26, 2026

Superfishintights commented on Aug 26, 2026

JoolsHattey commented on Aug 26, 2026

sdjg113 commented on Aug 27, 2026

evolsb commented on Aug 27, 2026

AwokenSpirit commented on Aug 28, 2026

wenjunjin88-alt commented on Aug 28, 2026

sdjg113 commented on Aug 28, 2026

kongjiellx commented on Sep 1, 2026

noahlevin commented on Sep 1, 2026

hwong103 commented on Sep 4, 2026

FoundationDigitalLabs commented on Sep 5, 2026

nachocab commented on Sep 5, 2026

What version of the Codex App are you using?

What platform is your computer?

What Remote client are you using?

What issue are you seeing?

Steps to reproduce

Expected behavior

Actual behavior

Additional diagnostics

Suspected cause

wuseal commented on Sep 5, 2026

Confirmed host-side workaround for saved Git projects

harryshawk commented on Sep 7, 2026

tension-zl commented on Oct 12, 2026

Additional reproduction: existing saved non-Git projects fail on Android, while desktop creation and remote continuation work

Environment

Observed behavior and reproduction

Host-side checks and confirmed workaround

Product behavior to investigate

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions