Linux desktop dictation substitutes “Spotify” for “Wispr Flow”

What version of the Codex App are you using?

Installed Linux package: openai-codex-desktop 26.901.51231-1 (verified through the package manager; the About dialog was not inspected).

What subscription do you have?

Not included in this report.

What platform is your computer?

Omarchy / Arch Linux, Hyprland (Wayland), x86_64.

What issue are you seeing?

The desktop chat app's built-in microphone transcribed the product name “Wispr Flow” as “Spotify” during a conversation comparing voice-to-text applications.

• Expected phrase, confirmed afterward by the speaker: Wispr Flow
• Actual text delivered to the assistant: Yes, go for the Spotify one.

The speaker explicitly confirmed using the microphone button inside the chat app, not the separate operating-system dictation shortcut. The incorrect product name changed the apparent request from a dictation application to an unrelated music application, causing an extra clarification round.

What steps can reproduce the bug?

Observed sequence on September 13, 2026:

1. Discuss Wispr Flow and Linux voice-typing alternatives in the desktop chat app.
2. Use the app's microphone to refer to Wispr Flow in a follow-up request.
3. The submitted transcription contains “Spotify” instead.
4. Correct the product name in a subsequent message.

This is a user-reported incident with the incorrect text observed in the conversation, not a deterministic reproduction. The original audio was not available for independent verification; the underlying speech-recognition model and failure stage are unknown.

What is the expected behavior?

Preserve the intended product name in dictated instructions. Consider improving recognition of names already discussed in the conversation, or offering a custom vocabulary/correction mechanism.

Additional information

Only the minimal incorrect phrase and relevant platform/version are included. No audio, full conversation, account information, workspace files, or diagnostic logs are attached.

The only named entry point is the desktop chat app's in-app microphone button; no source file or test is identified. Start by checking whether the report can be reproduced on the stated Linux/Hyprland setup, since the original audio is unavailable and the failure is explicitly non-deterministic. Done requires identifying the failing stage or obtaining a reliable reproduction before scoping a correction.