Intermittent /voice session failure on WSL2

[Igor-Mukhin]

I am posting that here, because "/feedback" gives me "Failed to upload feedback: feedback/upload failed in TUI". Please forward to whom it may concern.

Environment:

• Codex CLI 0.156.1 in Ubuntu 24.04 under WSL2
• WSLg PulseAudio: RDPSource input (mono, 44.1 kHz), RDPSink output (stereo, 44.1 kHz)
• ALSA default PCM is mapped to the PulseAudio plugin in ~/.asoundrc

Reproduction:

1. Run Codex in WSL and enter /voice.
2. Sometimes it fails immediately with “Voice audio devices could not open.”
3. Retrying may connect, allow several spoken turns, then fail after roughly a minute with:
   “Voice conversation failed: voice audio session stopped unexpectedly”

Audio recording and playback work outside Codex, both separately and simultaneously, through PulseAudio and ALSA. Adding the ALSA default mapping
changed the failure from an immediate device-open error to a later session failure.

The voice host appears to open the default devices through CPAL’s ALSA backend at 48 kHz, stereo, float32; the PulseAudio plugin connects these to
WSLg and adapts the formats. Realtime setup succeeds, and voice works briefly before failing.

Codex logs the later failure as phase=Device, exit_code=37. Inspection of the bundled voice host indicates this maps to its internal “audio device
failed” path, triggered by a CPAL stream-error callback. The helper does not log the original stream error or identify whether capture or playback
failed, so the underlying ALSA/PulseAudio error is unknown.

Could the voice host log the original CPAL/ALSA stream error and identify which stream failed?

[SpiritInAShell]

Hello, I experienced the same/a similar problem. I understand that you are on Windows using the WSL, so it is a large step to assume that my bare metal Linux setup has the same problem.

After multple interactive troubleshooting sessions with GPT-6-Astra (finally high, thanks to OpenAI for the global reset an hour ago!), it identified a specific cause and applied a local fix. Voice appears to work reliably (but needs actual use, after I got sleep).

• I only tried to make it work in general, until now. After "It works" I have not used it for actual work. /me needs sleep, after that session.
• important: user1 runs the desktop environment with unrestricted access, and user7 runs Codex CLI and does not have access to the X11 or other services per default.
  • running Codex CLI, tests from user1 worked without problems from the start.
• From the AI agent's description, it patched the audio library on byte level.
• I can confirm the problem as described below, but I cannot comment on the correctness of the reasoning of the agent. That is beyond me.

The agent wrote the summary below.

Setup

• Linux Mint 22.3 (based on Ubuntu 24.04 LTS) with an Xfce4 desktop session.
• Codex CLI 0.160.1 running under a different Linux user from the desktop session.
• PipeWire 1.0.5, providing PulseAudio compatibility.
• ALSA PulseAudio plugin from alsa-plugins 1.2.7.1 and libpulse 16.1.
• The Codex user accessed the desktop audio server through an existing loopback TCP listener, selected using PULSE_SERVER.
• ~/.asoundrc routed the default ALSA PCM through the PulseAudio plugin.

Symptoms
Initially, F8 reported that audio devices could not open. After configuring the ALSA-to-PulseAudio connection, voice remained intermittent: it sometimes worked, but usually stopped with:

“Voice conversation failed: voice audio session stopped unexpectedly”

Codex logged phase=Some(Device), exit_code=Some(37). Ordinary ALSA recording and playback worked, including simultaneous use.

Confirmed cause
A debugger captured the speaker/output-stream error:

ALSA function 'snd_pcm_avail_delay' failed with error 'I/O error (5)'

Further tracing stopped inside the ALSA PulseAudio plugin’s pulse_delay() function. It captured:

pa_stream_get_latency returned: -16
PulseAudio stream state: 2 (READY)
PulseAudio context error: 16 (PA_ERR_NODATA)

The plugin compared the function’s return value against positive PA_ERR_NODATA (+16). However, libpulse returned the negative error code (-16). Consequently, the plugin converted “timing information is not available yet” into a fatal -EIO instead of taking its existing path that waits for timing information.

The source-level correction is:

• if (err != PA_ERR_NODATA) {

• if (err != -PA_ERR_NODATA) {

This is in pulse/pcm_pulse.c, within pulse_delay():
https://github.com/alsa-project/alsa-plugins/blob/v1.2.7.1/pulse/pcm_pulse.c

Relevant libpulse implementation:
https://github.com/pulseaudio/pulseaudio/blob/v16.1/src/pulse/stream.c

Negative error-return definition:
https://github.com/pulseaudio/pulseaudio/blob/v16.1/src/pulse/internal.h

Local workaround and result
We copied the installed libasound_module_pcm_pulse.so into a private directory under my account and applied the equivalent one-byte correction to that copy. The patch was checked against the exact binary’s SHA256 and disassembly; it is build-specific and should not be applied blindly to another version.

We then added a pcm_type.pulse definition to ~/.asoundrc pointing to the corrected private library. The system library and Codex binaries were not modified.

Normal F8 voice operation now works without the debugger and continued working after logout/login. PULSE_SERVER remains persistently exported by my shell.

This confirms the cause on my machine. It does not establish that every exit-code-37 failure, or the failure reported here, has the same cause. However, it provides a specific check for systems using the ALSA PulseAudio plugin.

It would also help troubleshooting if Codex exposed the original CPAL/ALSA error and identified whether the input or output stream failed.

[SpiritInAShell]

#47370 (comment)

This user could solve his problem based on the above summary made by Astra@Codex. Have a look into it and please report, whether this worked for you.