Codex App cross-host handoff cannot discover matching saved project

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?

1. Connect two macOS hosts in Codex App.
2. On both hosts, save the same Git repository as a project at the identical path /Users/<user>/Work/<repo>.
3. 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"

1. From a separate local helper thread, call:

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

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