macOS desktop: repeated voice connection failures at approximately two hours

What version of the Codex App are you using?

Current installed macOS desktop app bundle reports 26.915.31945, build 9922. This is the installed version at report time, not a claim that every historical event occurred on this version.

What subscription do you have?

Not included in this public report.

What platform is your computer?

macOS 26.6.2 (25G83), MacBook Pro.

What issue are you seeing?

Voice repeatedly reports a connection failure at almost exactly two hours after starting. A review of retained desktop logs found 14 unique explicit Realtime voice connection failed events across September 12-19, 2026, Pacific time, spanning two tasks. Each was paired with its preceding same-task voice start. Elapsed durations range from 7,205.223 to 7,206.284 seconds; all report source webrtc.

This is a lower bound from retained logs, not an all-time incident count. Normal stops and diagnostic bundles were not counted as failures.

A normalized excerpt from the latest event:

T+00:00:00.000  realtime_session_started
T+02:00:06.284  Realtime voice connection failed; source=webrtc
20 ms later    thread/realtime/stop response; durationMs=6; errorCode=null

The regular timing suggests a session-lifetime or recovery boundary, but neither the server-side reason nor an intentional product limit is established. The app can still respond after the connection failure; this is not evidence of a whole-app crash or proof that background coding causes it.

What steps can reproduce the bug?

1. Start a desktop voice conversation.
2. Continue using voice in a long-running task.
3. Around two hours and five to six seconds after session start, the retained logs repeatedly show the connection failure above.

These are observed recurrence steps, not a newly forced minimal reproduction. I am not interrupting a currently working session to generate another failure.

What is the expected behavior?

If uninterrupted voice is supported, renew or reconnect cleanly. If there is an intentional duration boundary, present a clear reason and a usable recovery path rather than an unexplained connection failure.

Please investigate why the failures occur at this repeatable boundary, including whether this is intended session expiry and whether renewal/recovery is failing.

Additional information

Separate UI recovery report: https://github.com/openai/codex/issues/46822. It covers the voice activation button disappearing after a disconnect and failing to return without repeated application restarts. That UI recovery defect should remain actionable even if a duration limit is intentional.

Sanitized diagnostic metadata and private correlation information were submitted in the existing authenticated OpenAI Help Center conversation. Its automated response said it could not directly escalate or provide a case number. This report uses the GitHub issue route linked from the official desktop troubleshooting documentation.

No credentials, conversation content, account email, task identifiers, or raw log attachments are included here. Existing voice issues were searched; I did not find an exact duplicate establishing this repeated two-hour timing.

Start with the retained desktop logs around realtime_session_started and the repeated WebRTC failure at roughly 7,206 seconds. Compare the voice disconnect behavior with issue #46822, then determine whether the duration boundary is intentional and whether renewal or recovery fails. Done means the cause and expected recovery behavior are established.