Remote Control: Windows worker cannot discover originating macOS task for completion callback

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

• macOS controller: 26.901.51231, build 8109 (verified from installed app bundle metadata; bundle identifier com.openai.codex).
• Windows Remote Control host: MSIX 26.901.6511.0, AppVersion 26.901.51231 (from the Windows task's diagnostic, manually relayed by the user).
• Bundled CLI on both hosts: codex-cli 0.153.4 (Mac checked directly; Windows reported by its diagnostic).

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

• Controller: macOS 27.0, build 26A5425a. uname -mprs: Darwin 27.0.0 arm64 arm.
• Remote host: Windows 11 Pro Insider Preview 26H1 x64, build 28020.2818 (Windows diagnostic).

What issue are you seeing?

A task running on a connected Windows Remote Control host cannot return a completion report to the originating task on the Mac.

The Mac can discover a registered project on the Windows host, create a task in it, and send follow-up messages to that task. The Windows task performed the requested investigation and produced a feasibility report and verification results visible in its UI. However, the user observed the Windows task reporting that the Mac coordinator task could not be reached / found, and the report did not arrive in the originating Mac task.

The user also observed a Connections UI asymmetry: macOS offers Control this Mac, Control other devices, and SSH; the Windows installation offers Control this PC and SSH, with no Control other devices tab. Only the Mac-to-Windows connection was configured. This may explain why the Windows task has no independently discoverable Mac route, but it does not establish whether a completion callback is supposed to require reverse pairing.

The official Remote connections documentation says Mac and Windows devices can control hosts when Control other devices is available and that availability varies by rollout. Thus this report should not be read as claiming Windows universally lacks controller support.

The Windows diagnostic reported that list_threads returned only local; the originating Mac task and a route to its host were absent. The user manually relayed the callback arguments and the resulting error from Windows:

{
  "threadId": "<originating-mac-task-id>",
  "prompt": "<completion report>"
}

No Codex thread found for threadId: <originating-mac-task-id>. Hosts without a readable match: local

No hostId was supplied in that diagnostic callback. The task ID was the correct originating Mac task ID, and that task remained active on the Mac. The initial delegation had identified the Mac host as local from the Mac's perspective; the follow-up diagnostic explicitly warned that local is relative to the caller and asked the worker to discover a valid Mac route before retrying. The diagnostic found no such route. This leaves a discovery/routing limitation to investigate, rather than establishing a particular transport defect.

What steps can reproduce the bug?

Observed workflow:

1. Connect a Windows Codex host to Codex on macOS through Remote Control.
2. Register a project on that connected Windows host from the Mac.
3. From a Mac task, create a task in that remote project and ask it to report back to the originating Mac task when complete. Provide the originating task ID.
4. Confirm the remote task runs and accepts follow-up messages sent from the Mac.
5. Have the Windows task discover the originating Mac task and send its result back with send_message_to_thread.
6. Observe that the Windows task cannot reach/find the Mac task and its completion callback never arrives.

This report describes the observed cross-host workflow; it is not yet a minimal standalone reproduction.

What is the expected behavior?

A task delegated from the Mac to a connected Windows Remote Control host should be able to discover and address its originating Mac task and return a completion report. If reverse routing is unsupported, the task tools should make that limitation explicit rather than leaving the worker unable to find its origin.

Additional information

• The callback failure is the focus of this issue. Separately, the Mac's read_thread/wait_threads calls returned completed-turn metadata with empty items or no final assistant message even though the report was visible in the Windows UI. That resembles Codex Desktop: completed child turn visible in UI but read_thread returns items: []; it is not being treated as proof of the same root cause.
• Remote Control host discovery regression and SSH-host child creation/completion handoff issue are related routing reports, but neither establishes this Windows-to-Mac callback behavior.
• Host names, task IDs, and personal paths are omitted from this public report.

Start by reproducing the documented Mac-to-Windows workflow and inspect the list_threads and send_message_to_thread entry points. Trace how host discovery represents local and remote routes, then verify whether the Windows worker can resolve the originating Mac task. Done means the callback reaches the originating task, or the tools clearly report that reverse routing is unsupported.