What version of the Codex App are you using (From “About Codex” dialog)?
26.721.4979.0 (MSIX package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0; app-server client_version 26.721.41059)
What subscription do you have?
Pro 5x ($100)
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64 — Windows 11 Home Single Language, 24H2 (build 26100). GPU: Intel Iris Xe, driver 32.0.101.7085 (healthy, zero TDR events). 32 GB RAM. VBS/HVCI running.
What issue are you seeing?
Starting a voice conversation ends in "took too long to respond", and the app then exits silently — no Crashpad dump and no Application Event 1000.
Windows Code Integrity logs this at the exact second of each voice attempt (reproduced 15:10:57 and 15:21:43 local, 2026-07-28):
Code Integrity determined that a process
(\Device\HarddiskVolume3\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe)
attempted to load
\Device\HarddiskVolume3\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.
Immediately afterwards Get-AppxPackage OpenAI.Codex flips to Modified, NeedsRemediation, and Windows Update begins auto-repairing the package — observed re-staging all 9,539 payload files while the app was running, which killed the session mid-use.
This is the same underlying defect as #35505, #35635, #35411, #35352 and #34133. I am filing separately only because the three findings below are not covered in those threads — happy for this to be folded into #35505 if maintainers prefer.
Finding 1 — the IFEO mitigation override does NOT prevent the block
The obvious user-side workaround is to disable the mitigation for the image:
Set-ProcessMitigation -Name "ChatGPT.exe" -Disable MicrosoftSignedOnly
It applies cleanly. Get-ProcessMitigation -Name ChatGPT.exe afterwards reports:
MicrosoftSignedOnly : OFF
AllowStoreSignedBinaries : OFF
AuditStoreSigned : OFF
OverrideMicrosoftSignedOnly : False
The identical Event 3033 fired again on the very next voice attempt. The mitigation appears to be applied by the app to its own child process at spawn time, so per-image IFEO settings do not override it. Recording this so it does not get suggested as a fix.
For completeness, system policy is not the source: Get-ProcessMitigation -System reports MicrosoftSignedOnly: NOTSET, and no WDAC policy is enforced on this machine.
Finding 2 — voice mode is an independent trigger
The existing reports attribute the block to the in-app browser or to plain launch. Here it reproduces reliably by starting a voice conversation, which brings up the software-rendering path.
Finding 3 — the realtime media path itself is healthy
On one session where the GPU process happened to survive, the voice call worked end to end. App-server logs show normal two-way streaming:
realtime websocket connected ws_url=wss://api.openai.com/v1/live/rtc_u0_... status=101 Switching Protocols
realtime websocket event: {"type":"input_transcript.added", ..., "text":" Hey there"}
realtime websocket event: {"type":"output_transcript.added", ..., "text":" Hey!"}
Signaling (POST /backend-api/codex/realtime/calls returns 201 Created) and media both work, and direct STUN binding requests from this machine succeed in 12–13 ms. So the voice timeout is purely a downstream symptom of the GPU process being killed — not a networking, microphone-permission, or WebRTC problem.
What steps can reproduce the bug?
- Windows 11 with VBS/HVCI enabled. Install Codex Desktop 26.721.4979.0 from the Microsoft Store.
- Launch the app and start a voice conversation.
- The call fails with "took too long to respond"; the app exits silently shortly afterwards.
- Check
Microsoft-Windows-CodeIntegrity/Operational for Event ID 3033 naming vk_swiftshader.dll — timestamped to the voice attempt.
- Run
Get-AppxPackage OpenAI.Codex — status is now Modified, NeedsRemediation.
To confirm Finding 1: in an elevated shell run Set-ProcessMitigation -Name "ChatGPT.exe" -Disable MicrosoftSignedOnly, verify with Get-ProcessMitigation -Name ChatGPT.exe, then repeat steps 2–4. The block still occurs.
What is the expected behavior?
Voice mode should start without the GPU process being terminated.
The bundled SwiftShader/Vulkan binaries should either be loadable under the MSIX container signing-level enforcement, or not be loaded at all when hardware acceleration is available.
Critically, a blocked load should degrade gracefully rather than take down the app — chrome.exe logs the identical Event 3033 for its own vulkan-1.dll on affected machines and keeps running.
Additional information
A clean reinstall does not help. I ran a clean-room reinstall: package fully uninstalled, Delivery Optimization cache purged so the payload was re-downloaded from the CDN rather than reused, real-time AV disabled during staging, and Windows Update paused. The package validated Ok across two launch/quit cycles — then flipped back to Modified, NeedsRemediation at the exact second of the next Code Integrity block during a voice call.
Also reproduced here, consistent with #35505: Settings → Repair rewrites all 9,539 files and clears the flag, but the next launch re-trips it.
Ruled out on this machine, in case it saves anyone time:
- Microphone permission —
Allow for the packaged app in the consent store; mic hardware healthy
- Network / VPN — direct STUN binding requests succeed in 12–13 ms; SDP offers use trickle ICE and the call POST returns
201 Created
- GPU health — Intel Iris Xe driver reports OK with zero TDR events in 24h, and
Local State shows no latched software-rendering fallback (hardware_acceleration_mode_previous: true)
- Antivirus — no quarantine activity against the package during the incident window
No user-side workaround found: MSIX ACLs prevent launching the packaged executable with Chromium switches, no AppExecutionAlias exists for OpenAI.Codex to pass flags through, and the IFEO override is ineffective per Finding 1.
What version of the Codex App are you using (From “About Codex” dialog)?
26.721.4979.0 (MSIX package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0; app-server client_version 26.721.41059)
What subscription do you have?
Pro 5x ($100)
What platform is your computer?
Microsoft Windows NT 10.0.26100.0 x64 — Windows 11 Home Single Language, 24H2 (build 26100). GPU: Intel Iris Xe, driver 32.0.101.7085 (healthy, zero TDR events). 32 GB RAM. VBS/HVCI running.
What issue are you seeing?
Starting a voice conversation ends in "took too long to respond", and the app then exits silently — no Crashpad dump and no Application Event 1000.
Windows Code Integrity logs this at the exact second of each voice attempt (reproduced 15:10:57 and 15:21:43 local, 2026-07-28):
Immediately afterwards
Get-AppxPackage OpenAI.Codexflips toModified, NeedsRemediation, and Windows Update begins auto-repairing the package — observed re-staging all 9,539 payload files while the app was running, which killed the session mid-use.This is the same underlying defect as #35505, #35635, #35411, #35352 and #34133. I am filing separately only because the three findings below are not covered in those threads — happy for this to be folded into #35505 if maintainers prefer.
Finding 1 — the IFEO mitigation override does NOT prevent the block
The obvious user-side workaround is to disable the mitigation for the image:
It applies cleanly.
Get-ProcessMitigation -Name ChatGPT.exeafterwards reports:The identical Event 3033 fired again on the very next voice attempt. The mitigation appears to be applied by the app to its own child process at spawn time, so per-image IFEO settings do not override it. Recording this so it does not get suggested as a fix.
For completeness, system policy is not the source:
Get-ProcessMitigation -SystemreportsMicrosoftSignedOnly: NOTSET, and no WDAC policy is enforced on this machine.Finding 2 — voice mode is an independent trigger
The existing reports attribute the block to the in-app browser or to plain launch. Here it reproduces reliably by starting a voice conversation, which brings up the software-rendering path.
Finding 3 — the realtime media path itself is healthy
On one session where the GPU process happened to survive, the voice call worked end to end. App-server logs show normal two-way streaming:
Signaling (
POST /backend-api/codex/realtime/callsreturns201 Created) and media both work, and direct STUN binding requests from this machine succeed in 12–13 ms. So the voice timeout is purely a downstream symptom of the GPU process being killed — not a networking, microphone-permission, or WebRTC problem.What steps can reproduce the bug?
Microsoft-Windows-CodeIntegrity/Operationalfor Event ID 3033 namingvk_swiftshader.dll— timestamped to the voice attempt.Get-AppxPackage OpenAI.Codex— status is nowModified, NeedsRemediation.To confirm Finding 1: in an elevated shell run
Set-ProcessMitigation -Name "ChatGPT.exe" -Disable MicrosoftSignedOnly, verify withGet-ProcessMitigation -Name ChatGPT.exe, then repeat steps 2–4. The block still occurs.What is the expected behavior?
Voice mode should start without the GPU process being terminated.
The bundled SwiftShader/Vulkan binaries should either be loadable under the MSIX container signing-level enforcement, or not be loaded at all when hardware acceleration is available.
Critically, a blocked load should degrade gracefully rather than take down the app —
chrome.exelogs the identical Event 3033 for its ownvulkan-1.dllon affected machines and keeps running.Additional information
A clean reinstall does not help. I ran a clean-room reinstall: package fully uninstalled, Delivery Optimization cache purged so the payload was re-downloaded from the CDN rather than reused, real-time AV disabled during staging, and Windows Update paused. The package validated
Okacross two launch/quit cycles — then flipped back toModified, NeedsRemediationat the exact second of the next Code Integrity block during a voice call.Also reproduced here, consistent with #35505: Settings → Repair rewrites all 9,539 files and clears the flag, but the next launch re-trips it.
Ruled out on this machine, in case it saves anyone time:
Allowfor the packaged app in the consent store; mic hardware healthy201 CreatedLocal Stateshows no latched software-rendering fallback (hardware_acceleration_mode_previous: true)No user-side workaround found: MSIX ACLs prevent launching the packaged executable with Chromium switches, no AppExecutionAlias exists for
OpenAI.Codexto pass flags through, and the IFEO override is ineffective per Finding 1.