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

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?

Windows 11 build 26200, NVIDIA GPU, multiple 4K monitors with mixed refresh rates and HDR enabled on one panel.
Update the Codex app from 26.818.8289.0 to 26.820.7780.0 through the Microsoft Store.
Launch the app normally from the Start menu tile.
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.
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'

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:

Investigate the DirectComposition / swap-chain configuration change between 26.818.8289.0 and 26.820.7780.0.
Fall back from a failed presentation path instead of leaving a uniform blank client area.
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.

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

Windows 11 desktop app 26.818.3698.0 shows persistent blank white window #39882

Powered by Codex Action

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.

更正和补充数据：我需要撤回原报告中关于确定性的措辞。--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 像素即可区分渲染器扁平化、扁平化呈现和透明/不可见的故障。

如果需要，可以提供经过脱敏处理的会话指标和精确哈希值。我没有重复重置配置文件/软件包，因为全新状态、修复和重置操作本身就不具有选择性。

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

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.

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

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:

Back up the user config.
Write both complete default chrome themes with only opaqueWindows:true changed.
Quit normally from the tray.
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.

Correction to my immediately preceding recovery update: opaqueWindows:true is not a reliable containment.

After a full Windows restart, the same installed package (OpenAI.Codex 26.825.4187.0) launched normally with both raw themes still set to opaqueWindows:true and with the live config byte-identical to the earlier painted-launch checkpoint. It nevertheless produced a uniform opaque flat blank. Both screen capture and PrintWindow sampled 35,640 interior pixels at one luminance level, mean/mode 32, standard deviation 0.

The blank instance still reached main-frame load, ready-to-show, renderer route mount, and app-server connection without renderer-gone or load-failure markers. One exact-window RedrawWindow plus DwmFlush pulse returned API success but produced byte-identical before/after captures.

I then performed one normal tray Quit and one normal Store/Start launch. The new unflagged PID also remained uniformly flat blank with both raw opaqueWindows values still true and the same normal startup milestones.

This removes the earlier build-versus-setting confound: the same signed build and exact config bytes produced both a painted launch and a flat-blank launch. The setting only selects the opaque/no-material surface rather than the transparent/Mica surface; it does not make presentation reliable. Please treat my prior “effective containment” wording as superseded by this correction.

The Store currently offers no newer signed package on this machine. I am stopping local retry experiments rather than risking active tasks or applying system-wide graphics changes. A diagnostic build or product-side presentation fallback remains the safest next step.

Additional reproduction on a different hardware stack, with CDP-level diagnostics.

This appears consistent with the presentation failure described here, including the flat opaque and transparent client-area states.

Environment

Codex Store package: OpenAI.Codex 26.825.3734.0 x64
Embedded Chromium: 151.0.7922.174
Windows 11 25H2: 26200.9168
Dell Latitude 3440
Intel UHD Graphics: PCI\VEN_8086&DEV_4628&SUBSYS_0C1B1028
Intel graphics driver: 32.0.101.7077

Reproduction across Windows profiles

The same flat purple/blank client-area failure reproduces under two separate Windows user profiles on the same machine.

This makes per-user Codex state/auth/profile substantially less likely as the primary cause.

I also temporarily isolated .codex-global-state.json and allowed Codex to generate fresh global state. The rendering failure was unchanged. The original state was then restored byte-for-byte.

Renderer/application state is healthy

During a failed launch, logs and CDP show normal application startup:

main frame finishes loading
ready-to-show
React root render requested
routes mounted
authentication succeeds
app-server remains connected
config/account/model/thread IPC calls succeed
no renderer/GPU process crash observed

Via CDP, the main app://-/index.html page is fully populated:

document.readyState = complete
viewport = 1280x820
#root = 1280x820
bodyHTMLLength ~= 393194
rootHTMLLength ~= 392589
bodyTextLength = 1215
visibleElementCount = 943
elementFromPoint(center) = BUTTON

So this is not an empty DOM or failed React mount.

CDP screenshot is itself corrupted

The most interesting additional observation is that Page.captureScreenshot of the main renderer is already visually corrupted even though the DOM/layout above is populated.

I also injected a trivial fixed element through Runtime.evaluate:

position: fixed;
left: 100px;
top: 100px;
width: 600px;
height: 120px;
padding: 24px;
border: 8px solid red;
background: white;
color: black;
z-index: 2147483647;

with simple text inside it.

The DOM/layout recognized the element, but both:

Page.captureScreenshot(fromSurface=true)
Page.captureScreenshot(fromSurface=false)

produced visibly corrupted geometry/content: the background/border were rasterized in the wrong area and the text was detached/misplaced.

That seems useful for narrowing the boundary because the corruption is observable through Chromium's own CDP capture, not only in a normal Windows screen capture.

Verified ANGLE D3D11 vs SwiftShader A/B

Normal failed launch:

displayType    : ANGLE_D3D11
glRenderer     : ANGLE (Intel, Intel(R) UHD Graphics ... Direct3D11 ..., D3D11-32.0.101.7077)
gpuCompositing : enabled
rasterization  : enabled

I then launched the packaged MSIX through IApplicationActivationManager with:

--use-gl=angle
--use-angle=swiftshader
--remote-debugging-port=9222

and verified from the process command lines that the SwiftShader flag reached the browser and GPU processes.

SystemInfo.getInfo confirmed that the backend actually changed:

displayType    : ANGLE_SWIFTSHADER
glRenderer     : ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) ...), SwiftShader driver-5.0.0)
gpuCompositing : enabled
rasterization  : enabled

The failure remained, but changed phenotype: instead of the flat purple surface, much of the Codex client area became incorrectly transparent and exposed the window/desktop behind it.

During that state CDP still reported:

html background = rgb(23, 13, 45)
html opacity    = 1
body background = rgb(23, 13, 45)
body opacity    = 1
root opacity    = 1
root visibility = visible

This closely matches the transparent state already reported in this issue, but on Intel hardware and with the SwiftShader backend positively verified.

Other checks

Also tested without fixing the normal blank state:

--disable-direct-composition
--disable-gpu
--disable-gpu-compositing
DirectComposition/native-occlusion related switches
Intel graphics driver repair
fresh Codex global UI state
opaqueWindows = true in both Light and Dark chrome themes

With both opaqueWindows values set to true, a normal unflagged Start-menu launch still returned to the flat purple/blank state. The config was restored afterward.

I stopped local mutation/reset experiments at this point.

Overall this seems consistent with the boundary already identified in this issue: renderer/application startup succeeds, while something in the Chromium/Electron raster/compositor/window-presentation path produces flat or transparent surfaces.

I can provide the corrupted CDP captures, the injected-element captures, startup logs, SystemInfo.getInfo output, and the exact PowerShell/CDP reproduction commands if useful.

EDIT — clean version rollback A/B

I subsequently performed a controlled downgrade on the same machine, Windows installation, user profile, GPU driver, and Codex user state from:

26.825.3734.0

to:

26.818.8289.0

The x64 MSIX used for the rollback was a preserved copy of that release and was independently validated before installation against the known release metadata:

Version:
26.818.8289.0

SHA-256:
56B4F1667A69F0661F135EFF345F7369E3557A44514E93DC141662F6B50516AF

Authenticode:
Valid

Publisher:
CN=50BDFD77-8903-4850-9FFE-6E8522F64D5B

Architecture:
x64

The package identity was also confirmed as:

OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0

No Codex user state, configuration, Windows profile, GPU driver, or system graphics setting was changed as part of this A/B. The only intended variable was the Codex application version.

After the downgrade, I launched Codex normally from the Windows Start menu with no Chromium flags or custom launcher.

Result:

26.825.3734.0
→ flat purple / blank client area

26.818.8289.0
→ UI renders normally

The 26.818.8289.0 launch rendered correctly immediately.

This is the strongest result from this machine so far: the failure is reproducible on 26.825.3734.0 and absent after reverting the same environment to 26.818.8289.0.

That strongly supports a Codex application-side regression somewhere between these releases, rather than a persistent issue with the Windows profile, Codex user state, Intel driver, or machine-wide graphics configuration.

I am keeping 26.818.8289.0 installed for now and have stopped further local mutation/reset experiments.

建议追加到 GitHub issue #40878 的评论草稿

标题/开头可注明：更早阶段的变体：窗口根本不出现（renderer 未启动）+ 主进程 CPU 100% 忙等

Additional data point on the same version family, but a different, earlier failure stage than the blank-window reports above.

Environment: Windows 11 26200 (x64), Intel Core i9-14900HX + NVIDIA, 16 GB RAM.

Affected versions (all reproducible on this machine): 26.820.9563.0, 26.825.3734.0, 26.825.4187.0 (the latest Store-signed package from persistent.oaistatic.com/codex-app-prod/ChatGPT-x64.msix). The previous build 26.820.7780.0 worked (last successful use 2026-08-26).

Symptoms differ from the blank-window reports:

No window is ever created — MainWindowHandle == 0.
No renderer process is ever spawned (process tree is only main + crashpad + gpu + network utility).
Main process spins at ~100% of one core indefinitely.
App log stops after exactly two lines (Launching app, Appshot hotkey inactive); the next line ([dynamic-app-tools-native-pipe] dynamic_app_tools_listening) that appears on working builds never prints.
No WER/Event Viewer errors, no crashpad dumps, no renderer-gone or load-failure markers (because the renderer never starts).

Minidump evidence (procdump -ma of the stuck main process): 65 threads, all blocked at syscall return points in ntdll/win32u — ~22 threads in NtWaitForSingleObject (syscall 0x04), others in NtQuerySystemTime (0x09) polling. This looks like a startup barrier/event that is never signaled, with timeout-polling burning CPU.

Excluded (all tested, no effect): full reinstall of official MSIX, Reset-AppxPackage, cache clear, re-register, --disable-gpu, --no-sandbox, --disable-direct-composition (unlike the blank-window stage, this flag does nothing here), killing injected DLLs (Macified Dock, Nahimic), deleting singleton lockfiles, SQLite integrity (OK), proxy/network (OK), VC++ Redist/WebView2 present, VBS/CET not enabled, no Windows quality update installed around the break.

Hypothesis: this may be the same underlying 26.820.7780+ presentation/display-init regression (Chromium 151 on Win11 26200), hitting an earlier gate — the transparent/Mica window path may be failing at window creation on this machine rather than at first paint. If OpenAI needs a reproducer, I can upload the minidump and logs.

Still reproducible on Windows with Codex/ChatGPT Desktop 26.825.6671.0.

I am seeing the same blank white client area.

Troubleshooting performed:

Normal launch → blank white window
Killing all ChatGPT processes and reopening → still blank
Restarting Windows → still occurs
Fresh --user-data-dir → still blank
--disable-gpu → renders correctly
--disable-direct-composition → renders correctly
--disable-direct-composition also works correctly with my normal user profile

The main ChatGPT process creates the window successfully and reports Responding=True. GPU, renderer, network, and storage processes are also created.

Version:
OpenAI.Codex 26.825.6671.0

Current workaround:
ChatGPT.exe --disable-direct-composition

This appears to still be present in 26.825.6671.0.

A primary-source review of the current 26.831.2377.0 evidence changes two
parts of my earlier framing but does not change the observed failure:

The ASAR package metadata declares electron: 42.3.0, while the signed
executable reports 152.0.7977.64. Stock Electron 42.3.0 ships Chromium
148, while stock Electron 44.0/44.1 ship Chromium
152.0.7977.54/.65. This proves the shipped combination is non-stock; it
does not establish the actual Electron major. Could OpenAI provide the
build's runtime process.versions.electron, .chrome, .node, and .v8?
Electron's ready-to-show originates from Blink's visually-non-empty layout
signal. It is a layout milestone, not proof that a compositor frame was
submitted or presented. My startup logs should therefore be read as
main-frame/load/layout/app-route milestones only.

The current signed build still reproduces a visible, non-minimized,
non-cloaked but uniformly dark primary client after normal unflagged
activation, with renderer/GPU/app-server processes alive and both appearance
themes forced opaque/no-Mica. Direct screen capture verifies the visible
uniform client. I am no longer treating PrintWindow as independent evidence
for GPU-composited content. The observed client is near #202021, not the
configured native fallback #000000; this keeps both an empty/hidden web-app
layer and a later Viz/presentation failure open.

Native-window occlusion is also not ruled out, but it is lower-confidence here:
a prior direct run with
--disable-features=CalculateNativeWinOcclusion stayed blank, and
resize/maximize/restore plus cross-display move did not recover it. The
original public display context remains three 4K panels with mixed refresh
rates and HDR enabled on one panel.

Could a signed diagnostic build capture the following during the first blank
event, before user interaction?

runtime process.versions;
renderer ready/visibility, first-paint/FCP, app-root existence/child
count/bounds/computed background, center hit-test, and bounded rAF ticks;
primary BrowserWindow/WebContents visibility, bounds, lifecycle, crash/load,
and surface identity;
Viz root-surface activation, DrawAndSwap, submitted/aggregated frames, and
exact skip reasons; and
GPU feature/complete info plus swap-chain/DirectComposition/DWM presentation
outcome correlated to a direct screen sample.

I do not have a reliable local workaround to recommend. Opaque/no-Mica,
--disable-direct-composition, native repaint, geometry changes, transparency
changes, and normal relaunch have all been exhausted or proved
nondeterministic. I will avoid further resets, driver/display changes, or
retry loops and can validate one newer signed build or diagnostic at the next
natural occurrence.

Navigation Menu

Repository navigation

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

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

3. What subscription do you have?

4. What platform is your computer?

5. What issue are you seeing?

6. What steps can reproduce the bug?

7. What is the expected behavior?

8. Additional information

Environment

Reproduction across Windows profiles

Renderer/application state is healthy

CDP screenshot is itself corrupted

Verified ANGLE D3D11 vs SwiftShader A/B

Other checks

EDIT — clean version rollback A/B

建议追加到 GitHub issue #40878 的评论草稿

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

3. What subscription do you have?

4. What platform is your computer?

5. What issue are you seeing?

6. What steps can reproduce the bug?

7. What is the expected behavior?

8. Additional information

Activity

github-actions commented on Aug 26, 2026

TechMcKay commented on Aug 26, 2026

GQ105501 commented on Aug 27, 2026

jiayuan-ling-beiren-tech commented on Aug 27, 2026

nos1609 commented on Aug 28, 2026

TechMcKay commented on Aug 28, 2026

TechMcKay commented on Aug 28, 2026

LeonardiMaker commented on Aug 28, 2026

Environment

Reproduction across Windows profiles

Renderer/application state is healthy

CDP screenshot is itself corrupted

Verified ANGLE D3D11 vs SwiftShader A/B

Other checks

EDIT — clean version rollback A/B

shaohereshui commented on Aug 29, 2026

建议追加到 GitHub issue #40878 的评论草稿

leohdevstudio-debug commented on Aug 30, 2026

TechMcKay commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions