[Windows][Codex Desktop 26.901.6511.0] ~25s UI freeze during D3DCompile of ChatGPTAvatar Horizon shader

What version of the Codex App are you using (From “About Codex” dialog)?

26.901.6511.0

What subscription do you have?

Pro

What platform is your computer?

Windows 11 Pro, x64 OS build: 26200 14 logical CPU cores Intel Graphics / Direct3D 11 Intel GPU driver: 32.0.101.8826 Physical RAM: ~15.5 GB

What issue are you seeing?

Codex Desktop intermittently becomes unresponsive for roughly 25–30 seconds.

During the reproduced incident, the UI/composer became effectively unusable until the freeze ended. This can occur during normal Codex use and is not associated with a slow Git operation.

I captured the incident using Codex's built-in performance trace recorder and saved the trace locally.

Analysis of the captured trace shows a very strong GPU/shader-compilation stall:

• Renderer main thread blocked for ~25.003 s.
• The renderer waits through:
  GLES2Implementation::GetProgramiv
  -> CommandBufferHelper::Finish
  -> GpuChannel::WaitForGetOffsetInRange
• GPU worker executes D3DCompile for ~24.875 s.
• D3DCompile thread CPU time is ~24.707 s.
• The other D3DCompile calls in the same trace take only about 2 ms, 6 ms and 14 ms.
• The problematic translated HLSL shader is about 32,456 characters / 666 lines.
• The shader source identifies the internal material as:
  superassistant/Packages/ChatGPTAvatar/Resources/ChatGPTAvatar/HorizonShader/HorizonShader.metal
  and describes it as the ChatGPTAvatar "Horizon" material.

The long renderer stall begins approximately 33.5 seconds before the end of the trace and ends approximately 8.5 seconds before recording stopped, which matches the observed UI freeze.

Git does not appear to explain this captured incident. In separate workspace diagnostics, the measured full Git status was ~0.060 s.

What steps can reproduce the bug?

The issue is intermittent.

1. Open Codex Desktop on Windows.
2. Use Codex normally.
3. Start the built-in performance trace recording.
4. Continue using Codex until the UI lag/freeze occurs.
5. During the reproduced incident, the composer/UI becomes unresponsive for roughly 25–30 seconds.
6. Wait for responsiveness to return.
7. Stop the performance trace immediately afterward.

What steps can reproduce the bug?

This is a Codex Desktop UI/runtime performance issue rather than a bug triggered by user code, so I do not have a code snippet that reliably reproduces it.

The issue is intermittent.

Reproduction observed:

1. Open the Codex Windows desktop app.
2. Use Codex normally across one or more chats/tasks.
3. Start Codex's built-in performance trace recording.
4. Continue normal use until the UI lag occurs.
5. During the reproduced incident, Codex becomes effectively unresponsive for roughly 25–30 seconds. Typing and interacting with the chat UI are delayed or blocked.
6. Wait until the UI becomes responsive again.
7. Stop the performance trace shortly after recovery and save it locally.

The captured native performance trace contains one occurrence of the issue. Analysis of that trace shows the renderer waiting for the GPU while a D3DCompile operation for an internal ChatGPTAvatar/Horizon shader takes approximately 24.9 seconds.

No user code was being executed to trigger this shader compilation, so a standalone reproduction code snippet is not applicable.

Session ID: not available / no single Codex task session has been established as the trigger.
Token limit usage: not applicable or not available.
Context window usage: not applicable or not available.

The freeze appears to occur at the desktop UI/GPU renderer level rather than as a consequence of model token usage or context-window saturation.

What is the expected behavior?

Codex Desktop should remain responsive.

Compilation/linking of an internal ChatGPTAvatar WebGL/ANGLE shader should not block the renderer/UI for approximately 25 seconds.

Additional information

A native Codex performance trace captured the incident.

Local trace archive:
codex-trace-1788811089105.zip

ZIP size: 102,663,067 bytes
Uncompressed trace JSON: 884,968,678 bytes
ZIP SHA-256:
41026e0e4529a03faedf19c31a6121bea06fa8049e144fc6d110e6ed76536e96

I am not attaching the raw trace publicly because Chromium/Codex traces may contain local paths, application state, URLs or other potentially sensitive information.

I can provide the trace privately to OpenAI maintainers/support if needed.

Start with the captured Codex performance trace and the named ChatGPTAvatar HorizonShader.metal material, focusing on the renderer wait around GLES2Implementation::GetProgramiv and the D3DCompile event on Windows. Done means identifying a fix or mitigation that prevents the roughly 25-second renderer/UI freeze during shader compilation and verifying responsiveness during a trace.