Voice transcription for TUI

+1 this, I am having challenges to type since I have injured my right hand.
A dictation definitely is going to help me.

+1 this, I am having challenges to type since I have injured my right hand. A dictation definitely is going to help me.

Indeed. A lot developers have issues with RSI

The feature already existed, it was just recently removed in the last version. To get the latest working version on mac pin to version 0.117.0 with:

npm install -g @openai/codex@0.117.0

Then activate the feature with:

codex features enable voice_transcription

This feature should have never been removed in the first place!

also would be nice it it was some kind of shortcut/hotkey so it as simple as clicking the apple mic

Please support Linux PipeWire path!

Yes i recently started using codex more than claude code, and this is one feature that i feel is missing in codex, would love to have the voice mode just like claude code

I agree. Bring this back

I would really love to see this return in the TUI as well. The accessibility/RSI points others raised here resonate, and for daily CLI use a first-class flow would be much smoother than relying on external dictation.

The ideal shape for me would be a discoverable /voice command plus a push-to-talk shortcut or small mic control in the TUI, with the transcript editable before submitting. The comparison to Claude Code-style voice workflows is a useful reference point: quick spoken follow-ups are especially valuable when iterating with an agent.

PLEASE put it back, I've tried the CODEX desktop app but still prefer CLI + tmux.

I suggest a short spec for bringing TUI dictation back, aligned with the Electron app:

• Add a first-class TUI composer dictation flow, separate from Realtime voice conversation: shortcut starts/stops local recording, then inserts the transcript into the composer for review/edit before submit.
• Reuse the existing TUI microphone/device selection and metering path from realtime voice capture, but buffer the recorded clip instead of streaming PCM to thread/realtime/*.
• For ChatGPT auth, match the desktop app backend route: POST {chatgpt_base_url}/transcribe where the default base is https://chatgpt.com/backend-api. Send multipart audio plus ChatGPT OAuth headers from existing AuthManager / CodexAuth plumbing, including Authorization: Bearer ... and ChatGPT-Account-Id when available.
• Keep this explicitly gated to ChatGPT/Codex-backend auth for the desktop-compatible path. API-key auth should either show a clear unsupported message or use the public audio transcription API as a separately specified fallback.
• Prefer an upload format that the backend accepts consistently from Rust. The removed TUI prototype encoded buffered PCM as WAV; the Electron app uploads a MediaRecorder blob. First validation task should be confirming /transcribe accepts WAV with current backend behavior.
• Preserve the important UX details from the old prototype: minimum duration guard, visible recording/transcribing state, cancellation/error cleanup that does not lose existing draft text, and no auto-submit.

Relevant history: PR #16114 removed a partially completed TUI path that already did most of this shape: cpal capture, WAV encoding, ChatGPT /transcribe, and API-key fallback to /v1/audio/transcriptions. A revived version should reuse current auth helpers and desktop behavior rather than resurrecting the old direct auth-loading approach unchanged.

This was working quite well. Not sure why it was removed. Hope it's brought back. Important downgrade to codex

<img width="1313" height="307" alt="Image" src="https://github.com/user-attachments/assets/07bfd806-54e4-4284-9bd9-e9d2ce0e2483" />

Why tf do you guys add Pets as a feature, but not something basic like speech-to-text, that was already there in the first place.... @etraut-openai We need this back.

#27801 was just merged... removed the realtime voice support when you use an openai key

@etraut-openai why?

FYI for those maintaining their own codex forks, I implemented this in https://github.com/ignatremizov/codex/commit/16c09d4d5936f0c0878c02f72ef88e56c4880783 - based on my fork from base 0.140.0 + some other features.

Demo:

https://github.com/user-attachments/assets/1f867a03-5cf5-4db9-b7af-cb7f82eb174a

It mirrors the Codex App voice transcription backend path. No guarantee this keeps working if the backend contract changes - my fork sends captured PCM as a 24 kHz mono WAV upload, which is not the exact format the Electron app sends, but the backend accepted it in my testing. Also sends a Mac-style Codex Desktop user agent, because Linux user agents returned 403s from the transcription endpoint during my Ubuntu testing.

checkout/cherry-pick/resolve conflicts, and build a release for your machine to use. Or if you don't mind the other features I added, can download the linux artifact. the macOS build takes like 4+ hours on the github runners, I started a new build action run now, you can monitor if you want (or download if finished in the future).

note that linux-musl is not supported in my fork because dictation needs local microphone capture through cpal, and cpal’s Linux backend depends on native audio stack pieces like ALSA. I have not wired or validated those native audio dependencies for musl packaging, just linux-gnu since its what I mostly use. Works on macOS. Windows is not tested, but the code path is not disabled there, so should work also.

Relevant gates:

• tui/src/voice_availability.rs:4
• tui/Cargo.toml:128

Need to add voice_transcription = true under [features] in config.toml, and set /keybind for Composer Toggle Dictation (default is alt-m) - on my MacBook/iTerm this printed µ instead of sending option-m, so I rebound it to ctrl-i. Pick a binding your terminal emits :octocat:

Keymap config:

<img width="652" height="260" alt="Image" src="https://github.com/user-attachments/assets/2573212f-d40b-4c38-ab76-73ad3f699b8e" />

the pattern here is that dictation quality tracks who owns the audio path, not which model. a TUI shells out to the OS dictation engine, so you're stuck with whatever macOS hands it; the app pipes raw audio to a real transcription model before it ever reaches the prompt. routing the cli's dictation 'the same way' really means moving capture up into the client that wraps codex, not patching the TUI itself. once the wrapper owns input, voice stops being a per-tool afterthought and the same audio path holds whether the backend is codex or something else.

@m13v Not sure if this was aimed at my comment, but that’s not what my fork does.

I don't shell out to OS dictation, the TUI captures microphone audio itself with cpal, encodes it, and sends it to the same backend endpoint used by the Codex App dictation flow. The returned transcript is inserted into the composer.

So the client/wrapper already owns the audio path, that client just happens to be the TUI.

A shared app-server/client dictation API contract could be nice long term, especially across TUI, Desktop, remote exec, python SDKs, etc., but that is a larger API/design project, and less useful for my own maintenance while the Codex App and backend endpoint are closed source and subject to drift. Patching the interface people actually use solves the problem.