Before submitting
Area
apps/desktop
Problem or use case
Could it be possible for T3 Code Desktop to render an audio recording created by an agent directly in the chat timeline?
Today, when an agent creates an .mp3 or .wav file, the result is only a path/link and has to be opened in another app. This request is only about rendering an existing audio output—not microphone input or generating TTS.
Proposed solution
When an assistant message links to a supported local audio file, show a compact native audio player with play/pause, seeking, duration, filename, and an open/download action. Fall back to the normal file link if the recording cannot be loaded. Audio should never autoplay.
Why this matters
Audio-generating tools and skills would feel complete inside T3 Code: the user could review the actual result without leaving the thread.
Smallest useful scope
Desktop only; local MP3 and WAV files; one inline player when a linked file resolves successfully.
Alternatives considered
Opening every recording in an external media player.
Risks or tradeoffs
Missing or deleted files need a clear fallback. Local asset URLs should stay workspace-scoped, and large files should not be loaded eagerly.
Examples or references
Codex Desktop provides the target interaction: an audio recording returned in a response can be played inline.
Related but distinct: #3964 requests read-aloud/TTS, and #653 requests voice prompting. This request is only for rendering an audio file the agent already produced.
Contribution
Codex rendering example
Codex renders a linked recording as an inline player when the response uses image-style Markdown with an audio file path:
The angle brackets keep paths containing spaces valid. The requested behavior is the resulting in-app player, not the exact Markdown syntax.
Before submitting
Area
apps/desktop
Problem or use case
Could it be possible for T3 Code Desktop to render an audio recording created by an agent directly in the chat timeline?
Today, when an agent creates an
.mp3or.wavfile, the result is only a path/link and has to be opened in another app. This request is only about rendering an existing audio output—not microphone input or generating TTS.Proposed solution
When an assistant message links to a supported local audio file, show a compact native audio player with play/pause, seeking, duration, filename, and an open/download action. Fall back to the normal file link if the recording cannot be loaded. Audio should never autoplay.
Why this matters
Audio-generating tools and skills would feel complete inside T3 Code: the user could review the actual result without leaving the thread.
Smallest useful scope
Desktop only; local MP3 and WAV files; one inline player when a linked file resolves successfully.
Alternatives considered
Opening every recording in an external media player.
Risks or tradeoffs
Missing or deleted files need a clear fallback. Local asset URLs should stay workspace-scoped, and large files should not be loaded eagerly.
Examples or references
Codex Desktop provides the target interaction: an audio recording returned in a response can be played inline.
Related but distinct: #3964 requests read-aloud/TTS, and #653 requests voice prompting. This request is only for rendering an audio file the agent already produced.
Contribution
Codex rendering example
Codex renders a linked recording as an inline player when the response uses image-style Markdown with an audio file path:
The angle brackets keep paths containing spaces valid. The requested behavior is the resulting in-app player, not the exact Markdown syntax.