Codex App cross-host handoff cannot discover matching saved project #29284

Activity

1. lvtangjie-lyu

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 21, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   remote

   on Jun 21, 2026
3. Necmttn commented on Jun 21, 2026

   

   Necmttn

   on Jun 21, 2026

   More actions

   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.
4. leoxk commented on Aug 28, 2026

   

   leoxk

   on Aug 28, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. liang2h commented on Sep 3, 2026

   

   liang2h

   on Sep 3, 2026

   More actions

   Reproduced on macOS ↔ Linux (SSH) — Desktop 26.820.60940, matching fails even with fully working Git origin discovery

   Same failure mode as reported here and reproduced by @leoxk above, with one new data point: the destination is a Linux SSH host, so the affected surface is not limited to Mac↔Mac or Mac↔Windows pairings.

   As in the reproduction above, this rules out the Git 2.43 origin-lookup failure described in #37624: git config --get remote.origin.url succeeds on both hosts from the worktree root and returns byte-identical URLs. The failure therefore points at the host-qualified saved-project advertisement/matching layer, not at the origin query itself.

   Environment

   Component	Value
   ChatGPT desktop app	26.820.60940 (build 7119)
   Bundled local Codex CLI	0.150.0-alpha.8
   Remote Codex CLI	0.150.1 (also reproduced on 0.149.0)
   Source host	macOS 26.5.2, arm64
   Destination host	Linux, connected via SSH

   Verified facts

   • The local project is saved at the Git repository root on the source host, and the remote project is saved at the Git repository root on the destination host. Both report isGitRepository: true, and each saved path equals git rev-parse --show-toplevel on its host.

   • remote.origin.url is byte-identical on both hosts.

   • The destination host is online; remote-only chats run successfully against the same repository on it.

   • Reproduction rate: 100% across historical and newly created local chats, including a chat created after the desktop app update and formally assigned to the local saved project.

   • The run-location menu in the chat footer lists only local destinations; the SSH host is absent.

   • handoff_thread fails synchronously before an operationId is created:

     No matching saved project was found on <host>.
     

   Troubleshooting performed (no effect)

   • Removed and re-added the remote saved project multiple times; the project ID changed each time and the app kept reporting isGitRepository: true.
   • Restarted the SSH connection.
   • Upgraded the remote CLI 0.149.0 → 0.150.1 and retested.

   Regression information

   The same run-location menu previously offered the SSH host as a destination. The option disappeared after updating the desktop app. Nothing changed on either side in between: same checkouts, same origin, same repository roots.

   One observation that may help narrow the matching layer

   The two saved projects carry differently formatted IDs — the local one is a hashed local-… id while the remote one is a UUID, and the UUID changes on every re-add. This is consistent with the hypothesis that re-adding a folder creates a host-local project record without establishing the host-qualified saved-workspace association the handoff matcher consumes. This is an inference from observed behavior, not a confirmed root cause.

   Expected behavior per https://learn.chatgpt.com/docs/remote-connections#hand-off-a-chat-between-hosts: the SSH host should appear in the run-location menu, and handoff_thread should return an operationId and transfer the chat and Git state.

   Related: #37624 (failed origin lookup cached as null — ruled out here), #38872 (same symptom with a Windows destination).

   👍React with 👍1Reacted by Dez
6. nephaest commented on Oct 8, 2026

   

   nephaest

   on Oct 8, 2026

   More actions

   Additional reproduction on October 8, 2026: MacBook Air → Apple-silicon Mac Mini over the desktop Remote Control connection.

   Environment

   • Source ChatGPT desktop: 26.1002.52244 (build 13536), macOS 27.2.
   • Destination: macOS/arm64. Reported remote app-server version: 0.162.0-alpha.2 (observed in the connection details and October 7 logs; destination desktop build not collected).
   • Both devices use the Personal workspace; the user reports the same account/workspace.

   Reproduction and verified observations

   1. Save a local project at the Git repository root on each host. The two checkouts have different absolute paths but the same GitHub repository origin.
   2. Destination-local list_projects({}) returns the saved local project with a UUID projectId and its correct path (reported by the user from the destination chat).
   3. Source-local list_projects({}) returns source projects and ChatGPT projects, but no destination-local projects. This affects other destination projects too, according to the user's project inventory.
   4. From a separate source helper chat, call handoff_thread with the existing source thread ID and the connected destination host ID, without a follow-up prompt.
   5. It fails immediately with No matching saved project was found on <destination-host>. No operationId is returned.
   6. Crucially, read_thread from the source, explicitly targeting the destination host and a known destination chat ID, succeeds. The returned hostId is the remote-control destination and cwd is the destination saved project's path. The remote chat is readable and idle.

   Controls performed, with no resolution

   • Verified destination Git root using git rev-parse --show-toplevel and origin using git remote -v.
   • Initially the source origin used HTTPS and the destination used SSH. Temporarily set the source origin to the byte-identical SSH URL and retried: same handoff error. Restored the original source HTTPS URL afterward. This does not exclude stale origin caches or internal origin-query failures.
   • Created a harmless local chat within the previously empty destination project: still no destination projects in source list_projects, same handoff error.
   • Restarted the destination Mac and retried: same error.
   • Source desktop app had also been restarted during diagnosis.
   • An earlier attempt failed with a pending-composer-state error; later attempts progressed past that guard and consistently failed on project matching.
   • Source logs confirm a connected remote-control host and successful remote reconnection. An earlier Authenticated workspace changed disconnect coincided with closing/reopening the source app; a subsequent connection succeeded. That event is not established as causal.

   Expected behavior and impact

   The saved destination project should be discovered as a handoff candidate, allowing the existing chat and Git state, including uncommitted work, to transfer without starting another evaluation. The user is currently blocked from moving this workflow to the Mini. No transfer has taken place; the working files and branch remain intact.

   Qualification

   This appears consistent with this issue's destination saved-project discovery/matching failure, rather than a general inability to read remote chats. The precise cause (project enumeration, host-qualified identity, origin lookup/cache, or another matching field) is unconfirmed. We have not run the internal .git-directory origin query described in #37624, so that specific cause has not been ruled out.

   Please expose the destination candidates and compared repository identity fields, and distinguish a failed destination-project enumeration/origin lookup from an actual repository mismatch.

   Private repository names, usernames, absolute paths, chat IDs and host identifiers are intentionally redacted. No full session transcript or unreviewed logs are attached.