Linux voice helper fails to load PipeWire ALSA plugin from Ubuntu multiarch path

What issue are you seeing?

Codex 0.155.1's standalone Linux package fails to start voice mode on Ubuntu because the native voice helper tries to load the PipeWire ALSA plugin from /usr/lib/alsa-lib, while the installed plugin is in Ubuntu's multiarch directory, /usr/lib/x86_64-linux-gnu/alsa-lib.

The user-visible error is:

Failed to connect voice mode: voice connection failed

Instrumenting the helper showed that transport setup succeeded (transportReady). The failure occurred after openDevices, with this native stderr output:

ALSA lib external/alsa_lib+/src/dlmisc.c:339:(snd_dlobj_cache_get0) Cannot open shared library libasound_module_pcm_pipewire.so (/usr/lib/alsa-lib/libasound_module_pcm_pipewire.so: cannot open shared object file: No such file or directory)

The plugin exists at /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pipewire.so.

What steps can reproduce the bug?

1. Use the Codex 0.155.1 standalone package, release directory 0.155.1-x86_64-unknown-linux-musl, on Ubuntu 24.04 with PipeWire providing the default ALSA audio devices and its ALSA plugin installed in the multiarch directory above.
2. Start voice mode with the original bundled codex-resources/voice/bin/codex-voice-host.
3. Observe the generic voice connection failure during audio-device opening.

What is the expected behavior?

The bundled helper should discover the distribution's installed ALSA plugins and open the default audio devices. If device opening fails, Codex should expose the underlying audio error rather than only reporting a connection failure.

Additional information

Environment: Ubuntu 24.04.5 LTS, x86_64, PipeWire; Codex standalone 0.155.1. The musl-labelled distribution contains a GNU native voice helper.

Local workaround: rename the bundled helper to codex-voice-host.original and put a launcher at its original path that sets the variable inside the helper process environment:

#!/bin/sh
export ALSA_PLUGIN_DIR=/usr/lib/x86_64-linux-gnu/alsa-lib
exec "$(dirname "$0")/codex-voice-host.original" "$@"

Setting the variable only in the parent Codex environment was insufficient in our investigation because the helper launch filters environment variables. With the helper-level override, the trace progressed through transportReady, devicesOpened, and audioControlsApplied, and microphone input and audible replies worked.

This is a version-specific local workaround that an update can replace. The report concerns the confirmed plugin-loading failure; it does not claim that this explains every subsequent session disconnect.

The underlying diagnostic is also hard to discover: investigation found helper stderr discarded in realtime-webrtc/src/client.rs, and voice-host/src/main.rs discarding the run() error before exiting with status 1. Surfacing that error would make this failure much easier to diagnose.

Searched existing issues for ALSA_PLUGIN_DIR, voice + ALSA, and voice + PipeWire; found no matching report.

Reproduce the failure with the bundled voice helper on Ubuntu 24.04, then inspect realtime-webrtc/src/client.rs and voice-host/src/main.rs, which the report identifies as discarding diagnostic errors. Check how the helper environment is filtered and how run() failures are handled; done means the multiarch ALSA plugin loads and the underlying audio error is surfaced instead of only reporting a connection failure.