Codex App cross-host handoff cannot discover matching saved project

Open 💬 2 comments Opened Jun 21, 2026 by lvtangjie-lyu

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

26.616.51431 (build 4212)

What subscription do you have?

Unknown / not relevant to local desktop handoff

What platform is your computer?

Darwin 25.4.0 arm64 arm (both source and destination are macOS hosts)

What issue are you seeing?

Cross-host thread handoff aborts immediately with:

No matching saved project was found on <destination-host>.

Both connected Macs have the same repository registered as a saved Codex project, with identical redacted path and projectId. Remote thread listing and cross-host messaging work, but handoff cannot discover the destination project.

The failure is returned synchronously, before an operationId is created, so get_handoff_status cannot be used. Restarting Codex on both hosts and reconnecting the remote host did not help.

What steps can reproduce the bug?

Connect two macOS hosts in Codex App.
On both hosts, save the same Git repository as a project at the identical path /Users/<user>/Work/<repo>.
Verify on each host that list_projects({}) returns the project with:

projectId: "/Users/<user>/Work/<repo>"
projectKind: "local"
path: "/Users/<user>/Work/<repo>"
hostId: "local"

From a separate local helper thread, call:

handoff_thread({ threadId: "<source-thread>", destinationHostId: "<connected-remote-host>", followUpPrompt: "..." })

Observe the immediate error: No matching saved project was found on <destination-host>.

Additional verified facts:

The source thread's cwd is the saved project path.
A thread running on the destination host has the same cwd.
list_threads successfully enumerates destination-host threads, proving the remote connection/thread index works.
Running list_projects({}) locally on each host returns the same three saved projects and identical IDs/paths; each host labels its own entries hostId: "local".
The failure reproduced repeatedly, including after both Codex Apps were restarted.

This points to the host-qualified saved-project registration/discovery layer used by handoff_thread, rather than filesystem or Git path mismatch.

What is the expected behavior?

The destination host's matching saved project should be discovered, handoff_thread should return an operationId, and the source thread (plus associated Git state) should move to the destination host and run the follow-up prompt.

Additional information

Exact project paths, host names, destination IDs, and thread IDs are redacted because this is a public issue.

The local and destination list_projects views both show the project correctly, but neither exposes the other host's projects. It appears that hostId: "local" is relative to the calling host, while the cross-host handoff preflight is missing or failing to consume the destination's host-qualified project advertisement.

No project files were modified during diagnosis.

View original on GitHub ↗

2 Comments

Necmttn · 2 months ago

This needs a project-identity diagnostic before handoff aborts.

For each candidate destination host, the error should expose the compared fields:

source thread cwd/project id
destination saved project ids
canonical repo identity if available: git root, remote, worktree id
local path match result
host id used for routing

The handoff matcher should probably treat local path as one signal, not the whole identity. Same path on two hosts can still fail if host-local project ids differ; same repo at different paths should be recoverable if the user confirms. Without the comparison receipt, there is no way to tell whether discovery, host routing, or project identity failed.

---

_Generated with ax._

leoxk · 9 hours ago

I can reproduce this on two Apple-silicon Macs even after updating both hosts to the same Desktop build.

Environment:

Source and destination: macOS, Apple silicon
ChatGPT Desktop on both hosts: 26.820.80927
Git on both hosts: 2.50.1 (Apple Git-155)
Remote Control connection/websocket is healthy

Verified project identity:

The repository is saved at the same absolute path on both Macs: /Users/<user>/Workspace/<repo>
Git top-level path, HEAD, and normalized remote.origin.url match
The destination Desktop sidebar visibly contains the project
The same origin query used in the Git 2.43 report succeeds on both Macs, including when run from the repository's .git directory

Observed behavior:

handoff_thread fails immediately with No matching saved project was found on <destination-host>.
No operationId is created
The control/source host's list_projects only enumerates its local projects and does not expose the destination host's saved project
Re-adding the destination folder through the normal Desktop UI creates a second local project record for the same path, but does not create a remote/saved-workspace association and does not change the Handoff result
Restarting/reconnecting does not help

This appears distinct from #37624: both Macs use Git 2.50.1 and the origin lookup succeeds. It still looks like the Handoff preflight is not consuming the destination host's saved-project advertisement, even though the project is visible and usable on that host.

A supported diagnostic showing the source identity and destination candidates compared by Handoff would be very helpful. Please also clarify whether a destination project must be registered through any UI flow other than Add local project/Open folder.