Realtime voice: indicate silent post-turn processing with a subtle cue

What variant of Codex are you using?

Codex App — realtime voice mode.

What feature would you like to see?

After the user finishes speaking, realtime voice can enter a silent interval while Codex is actively processing the request. During that post-turn silence, users need a subtle, recognizable indication that work is still ongoing; otherwise the experience can feel stalled or disconnected.

Please add a client-side work-in-progress cue at the transition from user speech to active Codex work. Prefer reusing or lightly adapting the existing short voice-mode connection cue so the sound is familiar and consistent with the product. It should play once when silent processing begins, not while the assistant is speaking.

A restrained liveness reminder during unusually long silent work could be considered only if UX/accessibility research supports it. It should not become a loop or regular distracting pulse.

Acceptance criteria

• The cue is tied to the silent post-turn processing state: user speech has ended, Codex is still working, and assistant speech has not started.
• The cue plays once on entry into that state and does not replay because of duplicate or noisy state events.
• No work cue plays over assistant speech or during normal listening/input.
• The existing voice connection sound is reused or adapted where appropriate; no unrelated music is introduced.
• Output mute, user volume, and applicable sound/accessibility preferences are honored.
• The cue is short, subtle, and non-looping; any later liveness cue requires explicit UX validation and conservative throttling.
• The visual processing state remains available so the experience does not rely on sound alone.
• Focused tests cover state-transition gating, deduplication, mute/preferences, and suppression during assistant speech.

Additional information

The public openai/codex repository exposes the realtime app-server/core protocol, including realtime session and turn notifications, but it does not contain the Codex Desktop audio playback layer or the existing voice-mode connection sound implementation. This request is therefore intentionally aimed at the desktop client/product boundary. It does not propose speculative app-server audio generation or a new server protocol unless client implementation shows that one is actually required.