Native live voice for Codex threads using existing ChatGPT subscription access

[romil-bijarnia]

I'd like to discuss native live voice for Codex-backed T3 threads using the ChatGPT account already connected to T3. A connected user should be able to select an available subscription-backed voice and start a spoken conversation, including interruptions and task steering, in the current T3 thread. Voice must reuse that provider instance and account; it must not add another sign-in or a separate voice account. Someone without a connected account would use T3's normal ChatGPT sign-in once. This is not dictation into a draft or per-message text-to-speech. Requiring a separately configured or already authenticated CLI, an API key, or a separately billed API route would not satisfy the proposed user experience.

Before proposing a feature PR, I ran a bounded private feasibility check on Linux ARM64 with T3 commit 25bf84ab07 and the unmodified Codex backend bundled in the ChatGPT app (0.166.0-alpha.6). The connection used the existing ChatGPT OAuth login, not an API key or a custom Codex build.

The check imported T3's actual CodexProvider.withCodexAppServerClient helper and used its effect-codex-app-server client. It started an ephemeral thread and a V3 WebRTC voice session with sol. A browser sent synthetic speech, received the SDP answer, connected, and decoded the spoken response. The user and assistant transcripts matched the connection-test request and “Voice connection confirmed.” The browser received 1,203 Opus RTP packets with zero reported loss and measured nonzero decoded PCM samples. Stop was acknowledged.

A second bounded test started a synthetic interruption while remote speech was active. Counting stopped after “One,” and the replacement reply was “Interruption confirmed.” No microphone recording or changes to the installed T3 app were involved.

A subsequent bounded check also passed through the typed client using the ChatGPT account home configured for T3's existing Codex provider, rather than an unrelated global CLI login. It verified ChatGPT Pro authentication with no API key, decoded audio, both transcript roles, interruption and acknowledged stop. This supports reusing an existing T3 account connection without adding a second voice account. It still does not establish compatibility with T3's separate app-specific subscription-sharing token route.

T3 already has generated schemas for the voice notifications, but not the experimental realtime start/stop requests. The private check used the existing raw request extension point for those calls. This is provider/media feasibility evidence, not a native UI or a completed task integration. It did not establish access through T3's managed Sign in with ChatGPT/token-sharing path, attach to an existing T3 conversation, or prove cross-thread task coordination.

The proposed scope is Codex-backed live voice for the selected thread through its existing ChatGPT account connection in T3, with voice selection and explicit start, mute, stop, transcript, and failure states. Each user's own account must supply entitlement and usage; switching accounts must not leave a voice session using the previous user's credentials. Browser WebRTC would carry audio directly; T3's server would retain normal backend authentication and coordinate signaling. Shared upstream engine components may be internal implementation dependencies, not a separate CLI setup step for users. There would be no API-key fallback, copied account token in the browser, custom terminal voice bridge, or silent provider switch. Unsupported accounts or engine versions would report the actual failure.

The task boundary matters: voice-originated work must enter T3's orchestration and remain visible under its normal permissions and task accounting, rather than creating invisible backend work. Disconnect cleanup, session ownership, remote environments, and an explicit mobile support decision also need agreement. I have not implemented those product changes.

OpenAI's public documentation describes subscription voice in the ChatGPT app, but I have not found a public guarantee that this third-party subscription voice route is supported. The successful test does not settle long-term entitlement, distribution, or managed-token support. Those are dependencies to confirm, not assumptions to hide.

Would maintainers approve exploring this direction with the in-T3 account connection as part of the required scope? Which supported authentication route should that connection use for voice, and what support confirmation would you require from OpenAI before considering implementation? The successful existing-login probe is diagnostic evidence, not a proposal to leave users on an installed-CLI-only path.

Related but different: push-to-talk dictation #7417 and read-aloud responses #6762.

References: ChatGPT Voice, app-server, SIWC preview limitations, upstream Codex WebRTC signaling.