Voice transcription fails with 403 (Cloudflare HTML challenge) and silently drops transcript

Resolved 💬 7 comments Opened Feb 25, 2026 by etechlead Closed Feb 26, 2026
💡 Likely answer: A maintainer (Kbediako, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.105.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.3-codex xhigh

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

Powershell

What issue are you seeing?

Voice transcription results in getting the Cloudflare challenge page

.codex/log/codex-tui.log:

2026-02-25T18:24:43.334278Z ERROR codex_tui::voice: voice transcription error: transcription failed: 403 Forbidden <!DOCTYPE html>...

<img width="546" height="833" alt="Image" src="https://github.com/user-attachments/assets/aca2f7f2-d5cc-40a0-8540-36dc1a751e41" />

Every other thing works:

  • other Codex CLI features
  • ChatGPT in the browser
  • Codex App from the same outgoing IP

What steps can reproduce the bug?

  • hold space to record
  • speak, see the recording animation
  • release space, animation stopped
  • FAILURE 1 -> no text is inserted, textbox is cleared
  • FAILURE 2 -> no error message is shown

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

SlipstreamAI · 4 months ago

wish there was a feature that allowed us to see where theyre at with bugs in real time.. lol

Kbediako contributor · 4 months ago

I can confirm this is still reproducible on Windows 11 with codex-cli 0.105.0 using ChatGPT login.

What I observed on February 26, 2026:

  • voice_transcription = true is enabled, and Windows privacy settings confirm Codex accessed the microphone.
  • Holding Space records audio, but on release no transcript is inserted.
  • Re-auth (codex logout -> codex login) and a fresh session did not fix it.
  • Logs repeatedly show: ERROR codex_tui::voice: voice transcription error: transcription failed: 403 Forbidden
  • The response body is a Cloudflare challenge page from /backend-api/transcribe on chatgpt.com.

This looks like a backend/challenge-path failure rather than a local mic permission or keybinding issue.

etraut-openai contributor · 4 months ago

This feature is still under development and is not ready for use. We'll mark it as "experimental" when it's ready for use.

mgoldenbe · 4 months ago
This feature is still under development and is not ready for use. We'll mark it as "experimental" when it's ready for use.

@etraut-openai What's the reasoning behind merging it into main and causing countless people waste hours trying to get it to work?

eschulma · 4 months ago

It was listed as a new feature in the Release Notes. Well, I'm WSL anyway....

tagorr · 4 months ago

I’ve run a fairly exhaustive set of local diagnostics to rule out the usual suspects (mic permissions, FFmpeg, local STT, etc.), and I’m now confident this isn’t a “my machine” issue.

Environment

  • OS: Windows 10 LTSC 1809 (Build 17763).
  • Codex CLI: started on v0.105.0, reproduced again on v0.106.0.
  • Auth mode: ChatGPT login (confirmed via codex login status → “Logged in using ChatGPT”).
  • Local tooling present (for cross-checking only): Python 3.14 (experimental), FFmpeg 7.1, local Whisper installed with models available.

Local STT verification (to rule out “Whisper is broken”)

  • Manually ran Whisper against a known-good audio file:
  • Command: whisper test.wav --model base
  • Result: success, transcription returned.
  • Conclusion: local Python + Whisper binary + model download are functional, and a basic “wav → text” pipeline works on this machine.

Codex voice feature status and observed behavior

  • voice_transcription is enabled and the in-app voice UI indicator works (visualizer/equalizer reacts), but no transcript is inserted into the prompt.
  • Repro is consistent across Codex 0.105.0 and 0.106.0.

Attempts to “fix” transcription using Codex flags / modes

  • Disabled fp16:
  • Ran with --voice-transcription-fp16 false
  • Result: no change.
  • Forced CPU for Whisper/transcription (attempted to force non-GPU path):
  • Result: no change.
  • Tested codex exec mode:
  • codex exec -- "Record my voice" (or equivalent)
  • Result: the text agent responded that it does not have direct microphone access in this mode (expected, since push-to-talk is a TUI feature).
  • Bypassed approvals/sandbox:
  • --dangerously-bypass-approvals-and-sandbox
  • Result: no change.

Audio layer and Windows permissions checks

  • Microphone capture works outside Codex:
  • Verified with a separate microphone capture test script (audio recorded successfully).
  • Verified that the terminal environment (WezTerm) is not preventing microphone capture.
  • Windows Privacy settings:
  • Confirmed microphone access is allowed for desktop (classic) apps.
  • Media Foundation:
  • Confirmed mfplat.dll exists in System32 (file present).
  • FFmpeg:
  • ffmpeg -version succeeds; FFmpeg 7.1 is installed and available in PATH.

Temp / file-system observations (initial hypothesis)

  • Monitored %TEMP% during/after voice attempts.
  • Only saw .tmp files (0 bytes), no obvious WAV artifacts.
  • Initial working hypothesis was “buffer never flushes to disk”, but later evidence showed the actual failure is in the transcription request stage (network), not in local file output.

Encoding check (sanity check)

  • Observed PowerShell output encoding was US-ASCII.
  • Switched session encoding to UTF-8 (PowerShell + Python env).
  • Result: no change in behavior.

Logging and the decisive diagnostic signal

  • Ran Codex with Rust trace logging enabled and explicitly included the voice module:
  • Set RUST_LOG to include codex_core=trace, codex_tui=trace, and codex_tui::voice=trace.
  • Checked %USERPROFILE%\.codex\log\codex-tui.log.
  • Reproducible errors during voice dictation attempts:
  • ERROR codex_tui::voice: voice transcription error: transcription failed: 403 Forbidden ...
  • The response body begins with HTML and includes Cloudflare challenge markers, e.g.:
  • <!DOCTYPE html> ... <title>Just a moment...</title> ...
  • This 403 + HTML challenge appears repeatedly on each attempt.

Key diagnostic signatures to search for

  • In codex-tui.log:
  • codex_tui::voice
  • transcription failed: 403 Forbidden
  • <!DOCTYPE html>
  • Just a moment...

Main conclusion (what is actually broken)

  • Voice dictation fails because Codex’s transcription request (in ChatGPT-login mode) is being blocked upstream and returns a Cloudflare challenge page.
  • Evidence: repeated 403 Forbidden responses with HTML content (Just a moment...) logged by codex_tui::voice.
  • This rules out local audio capture, local Whisper/models, FFmpeg, Windows microphone privacy settings, and Codex fp16/CPU toggles as primary causes.

The decisive signal is in the logs: voice transcription repeatedly fails with 403 Forbidden and returns an HTML page containing Cloudflare challenge content (e.g. <!DOCTYPE html> and <title>Just a moment...</title>). In other words, the transcription request is being blocked upstream, and the feature fails silently in the UI.

Given this, I have a broader question about release communication: if voice transcription in the TUI is not reliably usable yet (at least for ChatGPT-auth users), why is it presented in the release notes as a shipped feature? Even a short note like “may fail under ChatGPT login due to upstream protection / 403” would save others from spending hours running local diagnostics like I did.

tagorr · 4 months ago

Update: still broken on 0.107.0 (stable)

  • codex --version: 0.107.0
  • codex login status: Logged in using ChatGPT
  • Voice UI reacts (visualizer moves), but no transcript is inserted into the prompt.
  • With RUST_LOG including codex_tui::voice=trace, codex-tui.log still shows repeated errors like: transcription failed: 403 Forbidden with a Cloudflare “Just a moment…” HTML challenge (truncated).
  • Same network/IP as browser ChatGPT, web ChatGPT works normally. This looks like an upstream block on the ChatGPT-auth transcription endpoint, not a local audio/permissions/FFmpeg/Whisper issue.