[Feature]: Support audio attachments from mobile clients

[Jerematix]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

packages/contracts or packages/shared

Problem or use case

T3 Code clients currently support text and image attachments, but not audio. On mobile, this means a user cannot record a voice note or select an existing audio file and send the original recording to a server-side agent.

This is different from local voice dictation or speech-to-text in the client. Some providers and agents can already process audio themselves—for example, Hermes can use Whisper and other audio tooling once a recording reaches the server—but T3's current attachment contract prevents the stock mobile app from transporting that recording.

Proposed solution

Add a provider-neutral audio attachment type across the client/server contract, including:

• filename, MIME type, byte size, and a stable attachment ID;
• bounded upload and server-side persistence alongside image attachments;
• recording and audio-file selection in the mobile composer;
• an attachment preview with playback, removal, and upload state before sending;
• capability-aware provider handling, with a clear error when a provider cannot consume audio directly; and
• a fallback that makes the persisted audio file available to filesystem-capable agents rather than silently dropping it.

Likely initial formats are the native iOS recording format (audio/mp4/M4A) plus WAV or MP3.

Why this matters

Mobile is a natural place to communicate with an agent through voice notes. Preserving the original recording lets the server-side agent choose the appropriate transcription or audio-analysis workflow instead of forcing every T3 client to own a transcription model or cloud speech provider.

This would unlock stock-client audio input for provider integrations such as the server-only Hermes ACP integration.

Smallest useful scope

A first version could be mobile-only:

1. select an existing M4A/WAV/MP3 file;
2. upload it under a server-defined size limit;
3. persist it with the thread; and
4. expose it to filesystem-capable providers as an attachment path when no native audio content block is available.

Microphone recording and web/desktop support could follow separately.

Alternatives considered

• Use the phone's dictation feature. This loses the original recording and prevents richer audio analysis.
• Upload the file through another service into the server workspace, then manually tell the agent its path. This works but bypasses the T3 thread and is cumbersome on mobile.
• Implement audio only in a private mobile fork. That would not work with the normal App Store client and would fragment the attachment contract.

Risks or tradeoffs

Audio files can be significantly larger than images, so limits, upload progress, cleanup, retention, and storage quotas need explicit handling. Provider capabilities differ, so unsupported audio must fail clearly rather than being omitted. Microphone permissions should remain opt-in.

Examples or references

• Hermes ACP integration fork: https://github.com/Jerematix/t3code-hermes
• Related voice-prompting discussion, focused on client-side speech-to-text: [Discussion] Voice support #653
• Related generic non-image attachment request: [Feature]: Any non-image file attachment support #2126
• Related rendering of agent-generated audio output: [Feature]: Render agent-generated audio files inline #4587

The Hermes fork intentionally keeps the released T3 clients unchanged, so it currently supports only the text and image attachment types that upstream T3 exposes.

Contribution

• I would be open to helping implement this.