›_ Codex Issues
Codex Issues / #40878

[Windows] Blank client area on 26.820.7780.0; --disable-direct-composition restores rendering

Open 💬 6 comments Opened Aug 26, 2026 by TechMcKay
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

2. What version of the Codex App are you using?

26.820.7780.0

(Store package version - worth a glance at Help > About Codex to confirm it matches.)

3. What subscription do you have?

ChatGPT Plus

4. What platform is your computer?

Run this in PowerShell, paste the single line it prints:

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

5. What issue are you seeing?

After the Microsoft Store update from 26.818.8289.0 to 26.820.7780.0, the app opens with a completely blank client area. The window, caption buttons and process are all alive - the renderer mounts, routes mount, auth succeeds, IPC round-trips complete, and remote control from the phone works normally - but the web contents never paint.

Launching the same signed package executable with only --disable-direct-composition renders the full UI correctly. That single flag is the entire difference.

This is not a machine-wide DirectComposition failure. Chrome 151.0.7922.175 and Edge 151.0.4129.107 both render normally on the same machine with DirectComposition enabled. Chrome is five patch revisions from the Chromium 151.0.7922.170 this build embeds.

Measurements. The client area below the caption strip was screen-captured and sampled by luminance. A blank window scores 1 luminance level and 0.000% deviation from the modal value - one flat color across ~190,000 sampled pixels.

| Configuration | Result |
| --- | --- |
| Unflagged, direct exe launch | Blank: 1 level, 0.000% |
| Unflagged, Store identity launch | Blank: 1 level, 0.000% |
| Unflagged, moved across all 3 monitors | Blank on each |
| --disable-features=CalculateNativeWinOcclusion | Blank: 1 level, 0.000% |
| --disable-direct-composition | Painted: 99 levels, 6.558% |
| Parsec virtual display adapter disabled, unflagged | Blank on both launch paths |
| Chrome 151.0.7922.175, own top-level window | Painted |
| Edge 151.0.4129.107, own top-level window | Painted |

Also ruled out: --disable-gpu, cache clearing, a full Reset-AppxPackage with a fresh profile, and package repair.

This produces no error signal. Every startup log line reports success - window ready-to-show, React root render requested, routes mounted, auth resolved, no renderer or GPU process-gone marker, no exception. Crash telemetry will show these sessions as healthy. This failure mode is only visible if a human reports it.

Hardware and display configuration:

  • Executable ChatGPT.exe, embedded Chromium 151.0.7922.170, package OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
  • NVIDIA RTX 5060 Ti, driver 32.0.16.1088 (2026-07-21)
  • Three 4K DisplayPort monitors: 160 Hz primary, plus two at 60 Hz with Advanced Color enabled on one
  • Mixed DPI: 175% user / 150% system
  • Onset: Store update installed 2026-08-25 20:22; Windows logged a MoAppHang for ChatGPT.exe at 20:29

6. What steps can reproduce the bug?

  1. Windows 11 build 26200, NVIDIA GPU, multiple 4K monitors with mixed refresh rates and HDR enabled on one panel.
  2. Update the Codex app from 26.818.8289.0 to 26.820.7780.0 through the Microsoft Store.
  3. Launch the app normally from the Start menu tile.
  4. The window opens and Windows draws its caption buttons, but the client area is a single flat color and never paints. The app is otherwise healthy: logs show the primary window ready-to-show, React root render requested, routes mounted and auth resolved, and remote control from the phone works.
  5. Quit the app, then launch the same executable directly with the flag:
$pkg = Get-AppxPackage -Name 'OpenAI.Codex' | Sort-Object Version -Descending | Select-Object -First 1
Start-Process (Join-Path $pkg.InstallLocation 'app\ChatGPT.exe') -ArgumentList '--disable-direct-composition'
  1. The UI renders correctly. Removing the flag reproduces the blank window every time.

7. What is the expected behavior?

The client area should paint the app UI, as it did on 26.818.8289.0 and as Chrome and Edge on the same Chromium 151 branch still do on this machine.

Secondarily: when a presentation path fails, the app should fall back to one that works rather than leaving a uniform blank surface. A window that renders nothing while reporting a fully successful startup is very expensive to diagnose, and invisible to your own telemetry.

8. Additional information

Two traps that cause false "already tested" claims. Both cost hours here and may be affecting other blank-window reports:

  • --disable-gpu does not bypass DirectComposition. On Windows, Chromium still presents through DComp with the GPU disabled, so that flag never exercises the broken path. "Tried --disable-gpu, still blank" does not rule out DComp.
  • Relaunching via explorer.exe shell:AppsFolder\<PFN>!App silently drops command-line arguments. Any flag test performed that way tested nothing.

Requests:

  1. Investigate the DirectComposition / swap-chain configuration change between 26.818.8289.0 and 26.820.7780.0.
  2. Fall back from a failed presentation path instead of leaving a uniform blank client area.
  3. Document a supported way to pass Chromium switches to the signed Store build. Launching the exe directly works and retains package identity and the AUMID, but it is not a documented path, and cold codex:// protocol activation has no way to carry the switch.

Possibly related: #34351 (different rendering symptom, but also Windows build 26200), #33192 and #38710 (other Windows DWM/composition reports).

Update: the flag is not a complete workaround. A launch ~2 minutes after a reboot
produced the blank window despite carrying --disable-direct-composition; a relaunch
~8 minutes after the same boot painted normally. Same build, same flag, same
machine. Either the presentation setup fails while the display stack is still
initializing after boot, or the flag reduces rather than eliminates the failure.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 day ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #39882

Powered by Codex Action

TechMcKay · 1 day ago

Correction and additional data: I need to retract the deterministic wording in the original report. --disable-direct-composition is not a complete workaround, and removing it does not reproduce the failure every time.

I now have 19 independently labeled launches on the same package and machine: 4 painted, 14 flat-blank, and 1 invisible/transparent. For the flag by itself, 3 of 7 launches painted and 4 of 7 were blank. Plain unflagged/Store launches were 1 of 5 painted and 4 of 5 blank. These runs were sequential and the sample is small, so that comparison should not be read as an estimated success rate; it only proves that the flag does not determine the outcome. Updating the NVIDIA driver from 32.0.16.1088 to 32.0.16.1656 did not remove the failure.

One earlier SwiftShader result also needs correction. A luminance-variation test classified it as painted, but desktop-background comparison showed that the client region was effectively transparent and exposing the desktop. The three observed states are therefore:

  • painted UI;
  • flat opaque blank surface;
  • invisible/transparent client surface.

I compared the first 20 seconds of all 19 corresponding desktop logs. Every state logged main-frame load, ready-to-show, renderer route mounting, and app-server connectivity, with zero startup errors and no startup renderer-gone, GPU-gone, or load-failure marker. ready-to-show timing overlaps completely between outcomes. The current telemetry cannot distinguish painted from blank or invisible.

Read-only inspection of this build's production Electron bundle shows the primary window uses titleBarStyle:"hidden" with a transparent title-bar overlay. Its surface is selected by the appearance theme: opaque mode uses a solid background plus backgroundMaterial:"none"; translucent mode uses #00000000 plus Windows Mica. The normal fresh-primary path is shown immediately and ready-to-show is logged, not used as a universal presentation gate.

The strongest current boundary is an intermittent Windows presentation failure after normal renderer startup, not a proven DirectComposition-only failure. The flag remains a possible mitigation, but the root cause could be in the Electron window surface, Chromium Viz/swap-chain setup, DWM/display initialization, or their interaction.

For a diagnostic build, the most useful missing signal would pair a privacy-preserving webContents.capturePage()/frame fingerprint with a Windows Graphics Capture fingerprint of the actual top-level window and a desktop-behind reference. That would separate renderer-flat, flat-presented, and transparent/invisible failures without uploading UI pixels.

Sanitized per-session metrics and exact hashes are available if useful. I have not repeated profile/package resets because fresh state, repair, and reset were already non-discriminating.

GQ105501 · 1 day ago
更正和补充数据：我需要撤回原报告中关于确定性的措辞。--disable-direct-composition这并非一个彻底的解决方法，而且移除它并不能每次都重现故障。 现在，我在同一台机器和同一软件包上进行了 19 次独立标记的发射：4 次标记已涂色，14 次空白，1 次不可见/透明。对于单独的标记，7 次发射中有 3 次标记已涂色，4 次空白。未标记/存储的普通发射中，5 次中有 1 次标记已涂色，4 次空白。这些运行是连续的，且样本量较小，因此该比较不应被解读为估计的成功率；它仅证明标记并不决定结果。将 NVIDIA 驱动程序从32.0.16.1088旧版本更新到新版本后32.0.16.1656，故障仍然存在。 之前 SwiftShader 的一个结果也需要修正。亮度变化测试将其判定为已绘制，但桌面背景对比显示，客户端区域实际上是透明的，并显示了桌面。因此，观察到的三种状态为： 绘制的用户界面； 平坦不透明的空白表面； * 不可见/透明的客户端界面。 我比较了所有 19 个对应桌面日志的前 20 秒。每个状态都记录了主机负载、ready-to-show渲染器路由挂载和应用服务器连接，没有启动错误，也没有启动渲染器丢失、GPU 丢失或负载失败的标记。ready-to-show所有结果的时间完全重叠。目前的遥测数据无法区分已绘制、空白或不可见的屏幕。 对该构建版本的生产版 Electron 包进行只读检查发现，主窗口使用了titleBarStyle:"hidden"透明标题栏叠加层。其表面由外观主题决定：不透明模式使用纯色背景backgroundMaterial:"none"；半透明模式使用#00000000Windows Mica 主题。正常的 fresh-primary 路径会立即显示并ready-to-show记录，但不会用作通用的显示门。 目前最明显的边界是渲染器正常启动后间歇性的 Windows 显示故障，而非已证实的仅 DirectComposition 故障。该标志仍然是一种可能的缓解措施，但根本原因可能在于 Electron 窗口表面、Chromium Viz/交换链设置、DWM/显示初始化或它们之间的交互。 对于诊断版本而言，最有用的缺失信号是将保护隐私的webContents.capturePage()帧指纹与实际顶层窗口的 Windows 图形捕获指纹以及桌面背景参考指纹配对。这样无需上传 UI 像素即可区分渲染器扁平化、扁平化呈现和透明/不可见的故障。 如果需要，可以提供经过脱敏处理的会话指标和精确哈希值。我没有重复重置配置文件/软件包，因为全新状态、修复和重置操作本身就不具有选择性。

你好你的这几个问题解决掉了没有？我今天突然也这样了、

jiayuan-ling-beiren-tech · 1 day ago

Confirmed on a newer Windows build of Codex Desktop: OpenAI.Codex 26.820.9563.0.

Symptoms:

  • App initially launched with multiple ChatGPT.exe processes but no visible main window.
  • After resetting/relaunching, the window eventually appeared but the entire client area was blank.
  • --disable-gpu did not help.
  • Launching the packaged executable directly with --disable-direct-composition immediately restored rendering:
$pkg = Get-AppxPackage OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation "app\ChatGPT.exe"
& $exe --disable-direct-composition

Package:

OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0

Embedded Chromium observed from the running process:

151.0.7922.170

I also tried reinstalling the Store app, Reset-AppxPackage, clearing/recreating the Codex profile, and --disable-gpu; none fixed the blank rendering. --disable-direct-composition did.

This appears to confirm that the DirectComposition rendering regression is still present in 26.820.9563.0.

nos1609 · 5 hours ago

I can reproduce the same blank-client-area phenotype on a newer ARM64 build after an app update.

Environment:

  • OpenAI.Codex Store package 26.825.3734.0 (Arm64, package status Ok)
  • Windows 11 Pro, build 28000, ARM64
  • Observed on 2026-08-28 at 09:18 Europe/Moscow

The top-level window is alive and shows the caption buttons, but the complete client area is one uniform cream-colored surface. No application UI paints. The blank window opens repeatedly after the update.

I have not tested --disable-direct-composition. This report extends the affected version and architecture matrix; it does not prove that DirectComposition is the cause on this device. I retained a screenshot for a private support channel.

I uploaded logs and diagnostics through /feedback.

Uploaded thread: 01a0470d-0700-71b0-8afb-875b432c5088

TechMcKay · 21 minutes ago

Recovery update — containment, not a root-cause fix.

Please treat the deterministic wording in the issue title/initial reproduction as superseded by the earlier 19-run correction and this update. A later live recurrence stayed black after resize/maximize-restore, moving the window between displays, turning Windows Transparency effects off, and one authenticated launch carrying --disable-direct-composition. The flag should not be relied on as a fix.

The currently installed Store package is OpenAI.Codex 26.825.4187.0 (internal app 26.825.32147, build 7303, Electron 42.3.0, Chromium 151.0.7922.174). Read-only inspection of its signed bundle shows that both shipped chrome-theme defaults still contain opaqueWindows:false. In the Windows main process, false selects a transparent background plus Mica; true selects an opaque background plus backgroundMaterial:"none".

A controlled containment worked:

  1. Back up the user config.
  2. Write both complete default chrome themes with only opaqueWindows:true changed.
  3. Quit normally from the tray.
  4. Launch normally from the Store/Start menu with no Chromium flags or custom launcher.

The UI appeared. Post-launch verification found a normal unflagged package process and both raw user-theme values still set to opaqueWindows:true.

There is an important confound: the 19-launch failure dataset was collected on package 26.820.7780.0, while this successful launch used both a newer package and the opaque override. I do not have a user-observed 26.825.4187.0 launch with opaqueWindows:false, so this result cannot isolate the setting from a possible build-side change. I am not switching the working app back merely to improve attribution.

The result makes opaque/no-Mica mode an effective containment on this machine and points more specifically at the transparent/Mica presentation path or its initialization. It does not prove the exact Electron/Chromium/Windows primitive or a permanent vendor fix. A future blank recurrence while both values remain true would be materially new evidence; a future signed build should be validated with normal activation before removing the override.

The unsafe local “Codex (safe rendering)” auto-heal shortcut and force-kill/retry payload have now been removed. Normal Store/Start-menu activation is the retained path.