Codex Voice on macOS disconnects after 15–20s with `Connection reset by peer (os error 54)` while text task continues
Summary
Codex Voice in the ChatGPT macOS desktop app consistently disconnects after approximately 15–20 seconds with a WebSocket read failure, while the underlying text conversation and Codex task continue running normally.
Exact error
Voice chat error: stream disconnected before completion:
failed to read websocket message:
IO error: Connection reset by peer (os error 54)
Reproduction
- Open a Codex conversation in the ChatGPT macOS app.
- Start Voice chat.
- Voice connects successfully.
- The assistant starts responding and the Codex task begins normally.
- After approximately 15–20 seconds, Voice disconnects with the error above.
- The text conversation and Codex task continue working after the Voice failure.
Frequency
Reproduces consistently across multiple Codex conversations.
Confirmed occurrences on July 26, 2026 at approximately:
- 10:45 Europe/Moscow
- 15:16 Europe/Moscow
- 15:55 Europe/Moscow
Environment / controls
- Platform: macOS
- Surface: ChatGPT desktop app / Codex Voice
- Web version works reliably on the same account and network.
- Restarting the macOS app did not help.
- Text mode remains functional after Voice disconnects.
- VPN is required for OpenAI access from the user's location and cannot be disabled. Different VPN exit servers/protocols can be tested if needed.
Related reports
- #14613 contains the same
Connection reset by peer (os error 54)error, including reports from users without VPN or proxy. - #35094 reports a separate but potentially related Realtime/Voice WebSocket failure path.
- Multiple open issues describe macOS Codex WebSocket instability and reconnect loops.
Expected behavior
Voice should remain connected for the duration of the session, or recover gracefully from a transient WebSocket interruption without terminating the Voice experience.
Actual behavior
Voice terminates after approximately 15–20 seconds, while the text task continues.
Request
Please investigate the server-side Realtime/WebSocket logs for these timestamps and confirm whether this is a known Voice transport or infrastructure issue. A client fallback/reconnect path would also prevent a transient transport reset from killing the Voice session.
Screenshots with the exact error and timestamps are available.
5 Comments
Additional environment details from a reproducible session:
26.721.4105926.5.25.6 Sol, High12189298and is intentionally not posted publicly.The exact behavior remains unchanged: Voice connects, the assistant starts responding, and after ~15–20 seconds the Voice WebSocket resets with
Connection reset by peer (os error 54), while the text conversation and Codex task continue normally. The web version remains stable on the same account/network.Additional reproduction details:
The same Voice failure reproduced on at least two different exit locations:
In both cases, Voice connects and works briefly, then disconnects after ~15–20 seconds with:
The underlying Codex text task continues normally, and the web version remains stable on the same account/network.
BlancVPN split tunneling is enabled only for Russian services; OpenAI/ChatGPT traffic is still routed through the VPN.
This weakens the hypothesis that the issue is tied to a single exit node. A controlled protocol comparison (AmneziaWG vs Xray) can be provided if maintainers specify which transport details would be most useful.
Deterministic silence-trigger identified
A much more precise reproduction condition is now confirmed:
This strongly correlates the bug with the idle transition rather than general connectivity. Suggested areas to inspect:
input_audio_buffer.timeout_triggeredExpected behavior: a silent pause should keep the session open, or trigger a normal follow-up such as “Are you still there?”. It should not terminate Voice with a WebSocket read error.
I am also facing this issue in macOS latest codex app. Seeing error "Voice chat couldn’t start
stream disconnected before completion: realtime call response missing Location"
Same issue here. Occurs only after user + assistant are silent for about 1-2min (earlier it occurred like after 20sec of bilateral silence).