Persistent "Unable to transcribe audio" issue

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #17434
• #18223

Powered by Codex Action

+1
Version 26.422.71525 (2210)

logged in codex with API key the error is failed to transcribe

I am seeing this same issue on macOS in Codex Desktop.

In-app bug report / thread ID: 019e032d-c890-73f3-830d-505a05e3c27c

Environment:

• Codex App: 26.429.61741 (codex@26.429.61741)
• Platform: Darwin 25.4.0 arm64 arm
• macOS: 26.4.1 build 25E253
• Electron: 41.2.0
• Subscription: Pro

Observed behavior:

• Dictation repeatedly fails with the user-facing message: Unable to transcribe audio
• This started this morning and still reproduces after retrying.
• My microphone setup has not changed.
• Local evidence does not point to a macOS microphone permission failure.

Relevant local Codex Sentry breadcrumb from the failure at 2026-05-07 10:20:33 CST:

[electron-message-handler] [Composer] dictation failed errorMessage="{\"detail\":{\"detail\":\"Transcription is temporarily unavailable. Please try again shortly.\",\"retry_after_seconds\":30}}" errorName=Error

This looks like the dictation request is reaching the transcription path, but the remote transcription service is returning temporary unavailability rather than Codex failing to access the microphone locally.

Same error on Windows 10 Pro
Codex 26.519.21041
Subscription: Pro 100

Same error on Mac M1
Codex Version 26.527.31326 (3390)
Subscription: Pro

Additional report from macOS Codex Desktop today.

Observed UI symptom:

Unable to transcribe audio

Context:

• Platform: macOS 26.5.1 build 25F80, arm64
• Local Codex CLI: 0.130.0
• The visible UI only shows the generic toast plus retry icon; it does not say whether the failure is microphone permission, capture failure, backend transcription failure, network, auth/org selection, or unsupported audio.
• From the UI it is unclear whether audio was successfully captured and failed during transcription, or whether capture never started.

User impact/request:

• Please expose a more actionable error message for dictation failures.
• If possible, include a recover/retry path and/or a pointer to relevant diagnostics/logs so users can distinguish local capture problems from backend transcription problems.

Up. Fix please

Got the same error "Unable to transcribe audio"

Mac M1
Subscription Pro

Got the same error "Unable to transcribe audio"
Mac M4
Subscription Pro

Same here: "Unable to transcribe audio"

Mac M1
Subscription Pro

Got the same error "Unable to transcribe audio"
Mac M4
Subscription Pro

Mine is up and running again - strange that I didn't do anything (didn't even update app)

Same

<img width="236" height="47" alt="Image" src="https://github.com/user-attachments/assets/a3d50a0b-5596-4ce9-9319-ac968fe59c0e" />

I ran into this issue on Codex Desktop for Windows. Dictation kept failing with “unable to transcribe audio.” My mic was not the real problem.

What we found: Codex was trying to send the audio to its transcription service, but instead of getting a normal transcription response back, it was getting a Cloudflare “enable JavaScript/cookies” challenge page. In plain English: Codex’s built-in browser/session got into a bad login/cookie state, so the transcription request was being blocked before it could actually transcribe anything.

The fix that worked for me was to fully reset Codex’s local web/session profile. This makes Codex rebuild its internal browser state. You will probably have to sign in again after doing this.

On Windows, open PowerShell and run:

Get-Process Codex -ErrorAction SilentlyContinue | Stop-Process -Force

$stamp = Get-Date -Format "yyyyMMdd-HHmmss"
$profile = "$env:APPDATA\Codex\web\Codex"

Rename-Item $profile "Codex-web-backup-$stamp"

explorer.exe "shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App"

After Codex reopened and I signed back in, dictation started working again on the first try.

Notes:

• Restarting Codex alone did not fix it for me.
• Clearing only cookies/cache helped a little, but did not fully fix it.
• The full reset of %APPDATA%\Codex\web\Codex is what fixed it.
• The old folder is not deleted; it is renamed as a backup.
• Do not try launching Codex directly from C:\Program Files\WindowsApps\...; Windows may block that. The explorer.exe shell:AppsFolder command is the correct way to relaunch the Store app.

________________________________________________________________________________________________________________________

UPDATE:

This was not actually fixed by the earlier cleanup/reset. Clearing Codex’s local web/profile/cache state made dictation work for a little while, but then the same problem came back. It went back to needing multiple clicks, refreshes, or just failing with “unable to transcribe audio.”

What we found after digging deeper:

The failure does not look like a microphone problem. It looks like Codex Desktop sometimes uses the older /backend-api/transcribe route, and that route can return a Cloudflare HTML challenge page instead of a real transcription response. When that happens, Codex reports it as a transcription failure.

The local workaround that made it work again was to force Codex Desktop to use the streaming dictation path instead of the older /transcribe path.

What we did locally:

• Copied the Codex Desktop app out of the protected WindowsApps install location into a normal local folder.
• Left the official Store-installed app untouched.
• Patched only the copied app.asar.
• Changed two dictation feature-flag checks so streaming dictation is always enabled.

In plain English: instead of letting Codex ask “should I use streaming dictation?”, we forced the answer to “yes.”

The two effective changes were basically:

• n = A(L) -> n = true
• t = oe(se) -> t = true

After that, dictation started working on the first click again in repeated tests.

Important: this is not a real upstream fix. It is an unofficial local workaround that proves the issue is likely in Codex Desktop’s dictation routing/fallback behavior, not the user’s mic.

The real fix should probably be:

1. Stop falling back to the old /backend-api/transcribe route for desktop dictation when it is returning Cloudflare/HTML instead of transcription data.
2. Prefer or force the streaming dictation path for affected desktop users.
3. Detect when the response is an HTML Cloudflare page and show the real error instead of treating it like a microphone/transcription failure.
4. Make the error message useful, because “unable to transcribe audio” is misleading here.

Short version: the earlier reset only helped temporarily. The issue came back. Forcing streaming dictation in the desktop app is what made it reliable again locally.

________________________________________________________________________________________________________________________

Update after more testing:

Forcing streaming dictation did not make the issue completely disappear, but it made the problem much less severe.

Before this workaround, Codex Desktop could get stuck failing indefinitely. I could click transcribe/send 15 times and it still would not go through, which meant I lost what I said.

After forcing streaming dictation on, I still occasionally get a failed attempt, but refreshing/retrying gets it to transcribe instead of being permanently stuck.

So the workaround is not a full fix, but it seems to change the failure mode from “completely unusable” to “intermittently flaky but recoverable.”

The original finding still stands: the old /backend-api/transcribe path can return a Cloudflare HTML challenge instead of transcription data, and Codex reports that as “unable to transcribe audio.” Forcing the streaming dictation path avoids that failure much of the time, but there also appears to be a separate intermittent startup/recording issue where an attempt may fail before it reaches transcription.