Cross-host Handoff fails for large chats because Windows drops segmented remote-control envelopes

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

Source Mac: 26.803.61601; destination Windows PC: 26.803.81509. The Windows build bundled app-server / CLI 0.147.0-alpha.6.6.

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Source: MacBook Air running macOS (Darwin 25.5.0 arm64 arm) Destination: Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Cross-host Handoff from the macOS Codex App to the Windows Codex App succeeds for a small test chat but consistently fails for an existing large chat. The large-chat transfer fails during step 2, while the UI says it is copying files to the destination host.

The user-visible error is:

Failed to continue on another host: Timed out waiting for MCP response to fs/writeFile

During the latest failing attempt, the destination Windows app-server logged 750 consecutive warnings in the following target:

codex_app_server_transport::transport::remote_control::segment

Every warning had the same message:

dropping invalid segmented remote-control client envelope

No fs/writeFile request from that Handoff attempt reached the Windows message processor. The transfer therefore timed out before the destination filesystem handler was invoked.

This appears to be related to the large-payload segmented Remote Control path. The same paired devices and repository successfully complete Handoff for a minimal chat that does not produce these warnings.

What steps can reproduce the bug?

1. Install and sign in to Codex App on a Mac and a Windows PC using the same account and workspace.
2. Pair the devices under Remote Connections and save the same local Git repository as a project on both hosts.
3. Keep the destination repository's normal checkout on its default branch.
4. On the Mac, open an existing large Codex chat associated with that repository and place it on a non-default branch.
5. In the chat footer, select the Windows destination and start Handoff.
6. Observe that preparation succeeds, but step 2 (copying files to the destination host) eventually fails with the fs/writeFile timeout shown above.
7. Inspect the Windows app-server logs for the same time window. They contain a burst of dropping invalid segmented remote-control client envelope warnings, while no Handoff fs/writeFile request reaches the message processor.
8. As an A/B control, repeat Handoff using a newly created minimal chat on another non-default branch. The minimal chat completes successfully on the same devices and repository and produces zero invalid segmented-envelope warnings in the exact Remote Control segment target.

The failure was reproduced more than once with the original large chat, including after restarting both apps and removing and recreating the device pairing. The private session/thread ID and conversation contents are intentionally omitted from this public report; a sanitized identifier can be supplied privately if an OpenAI maintainer requests it.

What is the expected behavior?

Handoff should transfer the current chat and Git state to the connected Windows host, create or reuse the destination worktree, and switch the chat to that host regardless of whether the chat payload requires Remote Control segmentation.

If a segment is invalid or incompatible, the app should report a specific protocol or reassembly error instead of surfacing only an fs/writeFile timeout.

Additional information

A/B evidence

• Small chat + non-default branch: Handoff succeeds.
• Original large chat + non-default branch: Handoff fails during file copying.
• Successful small-chat attempt: zero invalid segmented-envelope warnings in the exact segment target.
• Failing large-chat attempt: 750 consecutive invalid segmented-envelope warnings and zero Handoff fs/writeFile requests reaching the Windows message processor.
• An earlier small-chat attempt from the default branch reached a later Handoff stage and failed because the destination checkout was already using that branch. Retrying the small chat from a non-default branch resolved that separate Git worktree conflict. The large-chat failure still occurs from a non-default branch, so it is distinct from the branch conflict.

Troubleshooting already completed

• Restarted both Codex Apps.
• Removed and recreated the cross-host pairing.
• Verified that ordinary local file creation and deletion work on Windows.
• Verified sufficient free disk space and normal repository write access.
• Verified that the destination default checkout is clean.
• Used a non-default source branch to eliminate the separate worktree branch-conflict case.

Latest recorded reproduction

• Local time window: 2026-08-14 04:08:49–04:09:14 (Asia/Shanghai, UTC+08:00)
• UTC time window: 2026-08-13 20:08:49–20:09:14
• Invalid segmented-envelope warnings: 750
• Handoff fs/writeFile requests reaching the Windows message processor: 0

Assessment

My current inference is that the macOS sender and Windows receiver disagree on segmented-envelope encoding, validation, or reassembly for this larger Handoff payload. The Windows receiver appears to receive segmented traffic but discard it before reassembly can produce the fs/writeFile MCP request. This is an inference from the A/B behavior and logs, not a confirmed root cause.

The warning originates from the public Remote Control segmentation component:

https://github.com/openai/codex/blob/main/codex-rs/app-server-transport/src/transport/remote_control/segment.rs

I can provide a narrowly scoped, privacy-scrubbed log excerpt or private session/client identifiers if a maintainer requests them through an appropriate private channel.