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

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:

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

> Can't verify project trust for /Users/<user>/.codex/worktrees/<generated-UUID>/<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.

1. 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:

1. Connect the Android app to the Mac through Codex Remote.
2. Start a new Codex task with No project selected.
3. The task fails before starting with the same project-trust error for the generated projectless workspace.
4. 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:

1. Start a new Remote task with No project selected.
2. Remote creates ~/Documents/Codex/2026-08-25-test, then fails with the same project-trust error.
3. Retrying creates ~/Documents/Codex/2026-08-25-test-2 and fails identically.
4. Both generated directories are empty, user-owned, non-symlink directories and are not Git repositories.
5. Both ~ and ~/Documents/Codex were already explicitly marked trusted in ~/.codex/config.toml.
6. 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:

1. process/spawn runs a shell command that creates the unique YYYY-MM-DD-<prompt> directory.
2. Remote then issues config/read.
3. 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.

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.