Cross-host task creation drops attachments and leaves source-local paths unreadable
What issue are you seeing?
When a Codex Desktop task on one host creates or follows up on a task on another host through the built-in remote-project APIs, image/file attachments are not transferred.
The thread-management surface accepts prompt text, but does not expose attachment handles or payload fields. The resulting remote prompt may contain only a source-local path such as a file under the source host's Codex attachment directory. The destination agent then tries to read that path on the other operating system and fails because the bytes were never rehydrated there.
This is separate from repository/worktree setup: the remote task can initialize and execute normally while its referenced attachment remains unreadable.
Steps to reproduce
- Connect two Codex Desktop hosts with the built-in multi-device remote-project feature (for example, macOS controlling Windows).
- Start a local task on host A and attach a disposable PNG.
- From that task, create a fresh task in a remote project on host B, or send a cross-host follow-up, with instructions that require reading the image.
- Observe that host B receives prompt text but no attachment payload/handle.
- The destination agent attempts to open a host-A-local attachment path and reports that the file does not exist.
Expected behavior
Cross-host task creation and follow-ups should support first-class attachment transfer:
- the API should carry opaque attachment handles or bounded payload descriptors, not source-local filesystem paths;
- Codex should securely rehydrate each attachment into task-owned storage on the destination;
- the destination should receive MIME type, size, integrity hash, provenance, and lifecycle metadata;
- the destination agent should read matching bytes without needing SSH, SMB, shared queues, transcript synchronization, or another out-of-band copy;
- unsupported or failed transfer should be reported before remote task creation, rather than creating a task with an unreadable path.
Actual behavior
Only prompt text crosses the host boundary. Source-local attachment paths remain in the text and are unreadable on the destination.
Suggested acceptance test
Attach a disposable image on host A, create a remote task on host B, and require host B to:
- read the image from a destination-owned attachment handle/path;
- report the expected MIME type and byte length;
- compute a digest matching host A;
- prove the prompt contains no source-local attachment path.
Repeat the same test for a cross-host follow-up.
Additional information
Reproduced with signed Codex Desktop builds on macOS and Windows using the built-in remote-control project path on 2026-07-28. No repository transport or custom task transport was involved.