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.