Windows ChatGPT starts Codex/Work Voice from a normal Chat conversation and consumes weekly Codex quota
What version of the Codex App are you using (From “About Codex” dialog)?
26.810.52044
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
In the Windows ChatGPT desktop app, I am in a normal ChatGPT Chat conversation, not Work and not Codex.
When I click the voice button to start a voice conversation, the app silently switches the voice session into Codex/Work Voice instead of starting the normal Chat Voice experience.
As a result, my weekly Codex/Work usage quota is consumed even though I explicitly started voice from a normal Chat conversation.
There is no warning or confirmation before the mode changes.
The same account works correctly on chatgpt.com: starting Voice from a normal Chat stays in normal Chat Voice and does not switch to Codex/Work Voice.
My weekly Codex/Work usage quota has already been exhausted, and now starting Voice from a normal Chat conversation fails.
The failure appears to be caused by the previous unexpected routing of Chat Voice sessions into Codex/Work Voice, which consumed my weekly quota.
I can provide a screenshot showing that Voice cannot start because the quota has reached the limit.
What steps can reproduce the bug?
- Open the ChatGPT desktop app on Windows.
- Select ChatGPT and open a normal Chat conversation.
- Make sure the conversation is not in Work or Codex mode.
- Click the Voice button / "Start voice chat".
- Observe that the voice session switches into Codex/Work Voice.
- Continue speaking for a short period.
- Check Codex/Work usage and observe that the weekly quota has decreased.
This reproduces consistently for me.
On chatgpt.com, using the same account and starting Voice from a normal Chat does not reproduce the issue.
What is the expected behavior?
Starting Voice from a normal Chat conversation should start the normal Chat Voice experience.
It should not silently switch the session to Codex/Work Voice, and it should not consume the weekly Codex/Work quota.
If switching to Codex/Work Voice is intentional, the app should clearly ask for confirmation before consuming Codex/Work usage.
Additional information
I have attached a screenshot showing after reaching zero quota, the Voice startup failure.
<img width="1280" height="819" alt="Image" src="https://github.com/user-attachments/assets/d456d8e3-63d7-4d43-945b-27649829922a" />
<img width="1280" height="819" alt="Image" src="https://github.com/user-attachments/assets/69826f6a-6cf3-4f93-b5c7-5daa1042df20" />
Before the quota was exhausted, the issue was:
- I was in a normal Chat conversation.
- I clicked the Voice button.
- The session unexpectedly switched to Codex/Work Voice.
- My weekly Codex/Work quota was consumed.
- After reaching zero quota, Voice can no longer start.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This behavior aligns with issue #37619. Although the original report occurred on macOS while my environment is Windows 11, I am closing this issue in favor of #37619. Please refer to that thread for further context and details.
I can reproduce this issue on a newer Windows Desktop build, and I performed a fairly extensive elimination test because initially I suspected a local configuration or microphone problem.
Environment
Windows 10 Pro 22H2, build 19045
ChatGPT Plus
ChatGPT version shown in Help > About ChatGPT: 26.818.61809
Microsoft Store/MSIX package: OpenAI.Codex 26.818.8289.0
Release date shown in About dialog: 2026-08-24
The behavior is essentially identical to this issue:
Chat selected
→ start Voice
→ session is routed through Work/Codex realtime
→ Work/Codex usage is affected
The Voice button itself is NOT missing. It remains visible in normal Chat. The problem is what happens after pressing it.
Same-account A/B test
I tested the exact same ChatGPT account, PC, microphone, network, and time period.
Windows Desktop:
Chat selected → Voice → incorrect Work/Codex routing
chatgpt.com in Edge:
Chat selected → Voice → normal ChatGPT Voice works correctly
I directly completed a normal browser Voice session successfully.
This effectively rules out:
It also strongly points to a Desktop-specific routing problem.
Desktop log evidence
The affected Desktop Voice flow calls Codex thread-scoped realtime methods including:
method=thread/realtime/listVoices
method=thread/realtime/start
and successful attempts produce:
realtime_session_started hostId=local
realtime_session_updated ... rendererWindowAppearance=avatarOverlay
Some attempts fail with:
"thread <id> does not support realtime conversation"
followed by:
"Error starting realtime voice"
and:
"[avatar-overlay-realtime] Failed to start realtime in the avatar overlay"
So this is not only a UI labeling problem. The affected Voice flow is actually invoking the Codex/Work realtime thread route.
Additional UI/filesystem evidence
When I start Voice from a brand-new normal Chat conversation, the Recent list can show an automatically generated local path similar to:
C:\Users\<username>\Documents\Codex\2026-08-26\realtime-voice-chat-*
Multiple entries such as:
realtime-voice-chat
realtime-voice-chat-2
realtime-voice-chat-3
...
also appeared as Codex projects.
I did not intentionally create these projects. They were generated while reproducing Desktop Voice.
Local-state elimination
I initially suspected stale local Codex state.
I completely isolated/regenerated:
~\.codex\.codex-global-state.json
The Desktop app regenerated clean state, but the Chat → Work/Codex Voice routing problem remained.
Therefore the known stale realtime Voice thread pointer/local global-state class of problem does not explain this case.
I also tested Codex feature configuration.
The bundled codex.exe reports:
realtime_conversation under development false
There was originally no explicit realtime_conversation=true in my ~/.codex/config.toml.
As a controlled A/B test, I explicitly added:
realtime_conversation = false
and restarted the Desktop app without starting Voice.
Despite that, the Desktop startup log still reported:
Features enabled enabledFeatures="..., realtime_conversation"
followed by successful:
experimentalFeature/enablement/set
So the Desktop frontend enables its realtime feature independently of the local Codex CLI/config.toml setting.
I reverted the diagnostic config change afterward.
Electron/Statsig observation
The Desktop Electron profile contains Statsig evaluation cache data whose source is Network, and startup successfully calls:
POST /backend-api/wham/statsig/bootstrap
This makes a simple stale local feature cache/config explanation less likely.
I am NOT claiming the server-side Statsig assignment itself is necessarily wrong; the bug may instead be in how the Desktop client interprets the routing/handoff state.
Clean reinstall/reset elimination
Before collecting these logs I had already performed:
Windows app Terminate + Reset
full uninstall
Windows reboot
Microsoft Store cache reset (wsreset.exe)
fresh Microsoft Store reinstall
fresh normal Chat test
The issue persisted.
Therefore this does not appear to be ordinary MSIX package corruption.
AutoHotkey elimination
Earlier in the day I had experimented with AutoHotkey only to invoke the visible Voice UI.
However:
So AHK may have exposed the existing behavior during testing, but the evidence does not support it as the cause.
Why I believe this is a routing defect
The combined evidence currently looks like:
Normal Chat explicitly selected
→ user presses normal Chat Voice button
→ Desktop opens/uses the native realtime/avatar overlay
→ Codex thread/realtime APIs are invoked
→ a local realtime-voice-chat Codex workspace may be created
→ Work/Codex quota is used or can gate the session
while the same account on chatgpt.com uses normal Chat Voice correctly.
This also appears consistent with:
#38507 - Chat Voice incorrectly gated by exhausted Codex usage
#39986 - macOS Chat Voice launches as Work/Codex
The important part of my report is that this still reproduces on:
ChatGPT Desktop: 26.818.61809
Windows MSIX: 26.818.8289.0
and the Desktop logs provide direct evidence of thread/realtime/start being used during the affected flow.
Expected behavior
Chat selected → Voice must remain normal ChatGPT Voice.
It should not:
If useful, I can provide the specific timestamped Desktop log excerpts and screenshots showing: