[iOS Remote] Local MP3 embeds play on desktop but remain a loading placeholder on mobile

Environment

• Codex desktop on a Mac, accessed through Remote in the ChatGPT iOS app.
• Observed September 5, 2026.
• Exact desktop app version, iOS app version, and iOS version: not yet collected.

Problem

An assistant response embeds a locally generated MP3 using Markdown image syntax (![Listen to summary](/absolute/path/summary.mp3)). The user confirms that it renders as a playable audio attachment in Codex on the computer. Opening the same conversation in Remote on iOS instead shows a large dark rounded loading placeholder that never resolves. There is no playable audio control and no error message.

The user supplied an iPhone screenshot showing the empty placeholder and confirmed that this happens to the spoken summaries in this conversation. The screenshot is not included here to avoid exposing unrelated conversation content.

Steps to reproduce

1. In a Codex desktop conversation on a Mac, generate a short MP3 on the host.
2. Embed its absolute local path in the assistant's final response using ![Listen to summary](/absolute/path/summary.mp3).
3. Confirm that the user can play it in the desktop conversation.
4. Open the same conversation from the ChatGPT iOS app's Remote view.
5. Observe an unresolved loading placeholder, with no playback control or error.

Verification and scope

• Desktop playback and iOS failure are reported by the user; the reporting assistant cannot independently operate the user's iPhone.
• The local file was checked with file and ffprobe: MP3, 44,100 Hz, mono, 128 kbps, duration 11.310938 seconds, size 180,975 bytes.
• TTS generation completed successfully. This is about playback/delivery of an existing MP3, not realtime Voice or microphone input.
• Root cause is unconfirmed: it could involve Remote attachment delivery, local-path handling, media type detection, or mobile player support. No claim is made that the specific failing component has been isolated.

Expected behavior

The same attachment should be playable from Remote on iOS. If this media type or host-local attachment delivery is unsupported, the UI should provide a clear unsupported/error state instead of an indefinite loading placeholder, ideally with an available open/download action.

Impact

The user configured concise spoken summaries alongside assistant text to listen to responses from their phone. This works on desktop but makes that workflow unusable on mobile. Silent perpetual loading gives no recovery path.

Related

#38329 concerns audio player controls and HTTP sources; this report specifically concerns desktop-versus-iOS Remote playback of the same host-local MP3.

No credentials, private audio, absolute personal paths, full conversation transcripts, or device identifiers are included in this report.

Start by reproducing the desktop-versus-iOS Remote behavior with the supplied local MP3 steps, then trace Remote attachment delivery, local-path handling, media type detection, and mobile player support. Compare with related issue #38329; done means the MP3 plays on iOS or the UI shows a clear unsupported/error state with an available open or download action.