Windows: semi-transparent sidebar causes transparent/undrawn left and top regions when maximized

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

• #25217
• #25235
• #25154
• #25160
• #25236

Powered by Codex Action

Confirming a very similar issue on another Windows machine with the same Codex Desktop package.

Environment:

• Codex Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Codex CLI: codex-cli 0.135.0
• OS: Windows, 1920x1080
• GPU: NVIDIA GeForce GTX 1060 6GB
• GPU driver: 32.0.15.6094

Behavior:

• The left sidebar can render with stale content from a background window.
• I reproduced it with a clean Notepad window behind Codex containing only repeated BACKGROUND TEST text.
• The Notepad text visibly remains/bleeds through the Codex sidebar.
• The main content area renders normally; the issue is isolated to the left/sidebar composition area.
• Opening the Windows taskbar "Show hidden icons" system tray popup immediately forces the Codex sidebar to repaint correctly.

Troubleshooting tried:

• Restarted Codex Desktop.
• Reset zoom with Ctrl+0.
• Maximized/restored the window.
• Moved/minimized background windows.
• Disabled Windows transparency effects.
• Tried disabling GPU acceleration with:

[Environment]::SetEnvironmentVariable("ELECTRON_DISABLE_GPU", "1", "User")
[Environment]::SetEnvironmentVariable("WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS", "--disable-gpu", "User")

After fully restarting Codex Desktop with those variables set, the sidebar still rendered with stale background content.

Additional useful clue:

Opening the Windows system tray hidden-icons popup fixes the sidebar without changing anything inside Codex. That makes this look like a Windows repaint / DWM invalidation / app-window composition issue rather than corrupted sidebar data.

I have public-safe screenshots prepared:

• broken state: clean Notepad BACKGROUND TEST text visible through the Codex sidebar
• restored state: sidebar repainted correctly after opening the Windows system tray popup
• side-by-side comparison image

Small version clarification for my repro above: the Windows/MSIX package version is \\OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0\\, while the Codex About dialog shows app version \\26.527.31326\\. Codex CLI is still \\codex-cli 0.135.0\\.

Adding another environment confirmation for this same maximized-window transparent/undrawn sidebar issue.

Environment:

• Codex Desktop package: OpenAI.Codex_26.527.3378.0_x64__2p2nqsd0c76g0
• Chromium/app process version observed from Codex process args: 148.0.7778.179
• OS: Windows 10 Pro 10.0.19045 x64
• Display: 1920x1080, 100% scaling (--device-scale-factor=1)
• GPU: NVIDIA GeForce RTX 3070
• GPU driver: 32.0.15.8180 (2025-10-29)
• Additional display adapter present: GameViewer Virtual Display Adapter (15.6.5.199)

Behavior:

• The issue appears specifically when the Codex window is maximized.
• Restored / non-maximized window mode renders normally.
• When maximized, the left/sidebar region can become transparent or undrawn and show desktop, terminal, or other-window content behind Codex.
• The main conversation/content area continues to render normally.
• This looks like the same Windows DWM / Chromium compositor / app-window clipping class of bug described here and in #25217 / #25235, rather than corrupted thread data or workspace content.

One useful extra data point: this confirmation is on an NVIDIA RTX 3070 system, while the original report here is on AMD RX 6750 XT. That suggests the issue is not limited to one AMD driver path.

I prepared a sanitized reproduction/annotation image locally, but gh gist create cannot upload binary PNG files (binary file not supported) and this browser session is not signed into GitHub for drag-and-drop attachments. The image redacts private desktop icons, project names, paths, terminal output, and conversation text; it only preserves the visual structure of the failure.

Attaching the sanitized reproduction/annotation image referenced in my previous comment.

It redacts private desktop icons, project names, paths, terminal output, and conversation text while preserving the relevant visual structure: the maximized Codex sidebar/left region becomes transparent or undrawn, while the main content area renders normally.

<img width="1920" height="1040" alt="Image" src="https://github.com/user-attachments/assets/668586e9-b279-4039-b562-acfab0591251" />

Follow-up after code-aware cross-review and local toggle testing:

I had Codex, Claude, and Gemini independently review the shipped bundle excerpts and the local reproduction evidence. All three reviews converge on the same likely fault boundary: this does not look like corrupted sidebar data or a sidebar layout bug, but the Windows transparent Electron window-surface / translucent-sidebar composition path.

The shipped bundle shows the Translucent sidebar toggle is implemented as the inverse of the theme field opaqueWindows (checked: !theme.opaqueWindows, then opaqueWindows: !checked on change). When opaque mode is active, the app applies .electron-opaque, which paints the Electron root/body with solid backgrounds; when translucent mode is active, stale background pixels can show through until a Windows shell overlay such as the hidden-icons tray popup forces a repaint. That also explains why the main content area remains normal: it appears to be painted opaque, while the sidebar is the visible translucent region exposing the transparent window surface.

ELECTRON_DISABLE_GPU=1 did not prevent the issue, so plain GPU disable is not sufficient. WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--disable-gpu is likely irrelevant here because the shipped app is Electron/Owl Shell rather than WebView2.

The highest-value next bisection would be to test the existing compositor debug switches separately:

• forceOpaqueRendererBackground: if this fixes it, the transparent window surface is likely the trigger.
• disableBackdropBlur: if this fixes it, the culprit is more likely the backdrop-filter blur repaint path.

So the current best summary is: the issue is very likely in the transparent-window / opaque-window transition and repaint invalidation boundary, with the semi-transparent sidebar being the user-visible trigger.

Adding more concrete shipped-bundle coordinates for maintainers. I could not find these symbols in the public openai/codex repo via GitHub code search, so these appear to come from the Desktop app bundle rather than source currently exposed in the public repo.

Package:

• OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• app/resources/app.asar

Note: these are minified shipped bundle coordinates, so line numbers are less useful than char offsets / nearby symbols. The sourceMappingURL comments are present, but .map files do not appear to be included in the shipped app.asar.

Relevant bundle coordinates:

• webview/assets/general-settings-CFpJgfrw.js
• settings.general.appearance.chromeTheme.translucentSidebar.short
• char offset 13569, minified line 11, column 1637
• identifies the visible Translucent sidebar setting.
• webview/assets/general-settings-CFpJgfrw.js
• checked:!y.opaqueWindows
• char offset 17987, minified line 11, column 6055
• confirms the toggle is inverse-wired to opaqueWindows.
• webview/assets/general-settings-CFpJgfrw.js
• v({opaqueWindows:!e})
• char offset 18025, minified line 11, column 6093
• confirms changing the toggle writes the inverse opaqueWindows value.
• webview/assets/app-main-5RivLWkW.css
• [data-codex-window-type=electron].electron-opaque
• char offset 473935, minified line 1, column 473936
• paints the Electron root/body with solid backgrounds in opaque mode.
• webview/assets/app-main-zLGqsQIL.js
• electron-window-opaque-surface-changed
• char offset 384144, minified line 2, column 362630
• subscribes to native/window opaque-surface state.
• webview/assets/app-main-zLGqsQIL.js
• classList.add(\electron-opaque\)
• char offset 385055, minified line 2, column 363541
• applies the opaque class when opaqueWindowSurfaceEnabled is true and the window is not compact.
• webview/assets/app-main-zLGqsQIL.js
• classList.remove(\electron-opaque\)
• char offset 385097, minified line 2, column 363583
• removes the opaque class otherwise.
• webview/assets/general-settings-CFpJgfrw.js
• settings.general.gpuTearingDebug.forceOpaqueRendererBackground.description
• char offset 54185, minified line 11, column 42253
• description says it paints the renderer root/body with opaque backgrounds to isolate transparent-window composition.
• webview/assets/general-settings-CFpJgfrw.js
• settings.general.gpuTearingDebug.disableBackdropBlur.description
• char offset 53019, minified line 11, column 41087
• description says it forces backdrop filters off to reduce layered blur composition.

Concrete fix direction suggested by the evidence:

1. If the intended Windows behavior does not require the native window itself to be transparent, prefer keeping the Windows/Electron surface opaque and implement the sidebar's visual treatment inside the app surface only. That would avoid exposing stale pixels from windows behind Codex.
2. If native transparent windows are required for the design, then the likely fix is in the native opaque-surface transition / invalidation path: when opaqueWindows changes or when the window becomes maximized/restored/focused, force a full repaint/invalidation of the transparent surface region.
3. The best bisection remains the two existing debug switches:

• forceOpaqueRendererBackground: should confirm whether an opaque root/body eliminates the artifact.
• disableBackdropBlur: should confirm whether the issue is specifically backdrop-filter composition rather than the transparent window surface itself.

Given the readable background text showing through, my best current bet is the native transparent surface path rather than just blurred-backdrop repaint, but the two debug switches should settle that quickly.

I also encountered this problem.

I can reproduce a very similar rendering/layering problem on Windows 10 with Codex Desktop 26.527.31326.

Observed behavior:

• When the Codex Desktop window is maximized, parts of another Chrome/webpage window appear through or mix with the Codex UI.
• The left sidebar/content area and the top-right window control area show the clearest artifacts.
• It looks like an overlay / z-index / window compositing layer issue triggered by maximized state.
• The issue is much more visible when a Chrome window is behind or beside Codex.

Expected behavior: maximized Codex Desktop should fully repaint/cover its own window area, with no transparent or mixed regions from other windows.

User-provided screenshot shows the left content/sidebar and top-right titlebar/control area outlined in red where the layering breaks.

I can reproduce this too, and disabling Settings -> Appearance -> Semi-transparent sidebar immediately fixes it.

Environment:

• OS: Windows 10 Pro, version 10.0.19045, build 19045
• GPU: NVIDIA GeForce RTX 3080
• NVIDIA driver: 32.0.15.9597
• Driver date: 2026-03-16
• Display: 2560x1440
• Codex package: OpenAI.Codex_26.527.7698.0_x64__2p2nqsd0c76g0
• Codex Chromium/runtime version observed in process args: 148.0.7778.179
• Runtime installed at: 2026-06-01T17:19:28.117Z

Behavior:

With semi-transparent sidebar enabled, maximizing the Codex window causes the app shell/sidebar/titlebar area to become transparent or unpainted. Restoring the window makes it render normally again. Turning off semi-transparent sidebar fixes maximized rendering immediately.

This makes it look GPU-vendor independent, since the original report is AMD and this reproduction is NVIDIA.

Turning off Semi-transparent sidebar fixes the problem on light theme but not for dark theme

I encounter this issue too.

I can reproduce this consistently on Windows 10.

Environment:

• OS: Windows 10
• GPU: Intel(R) Iris(R) Xe Graphics
• Multi-monitor setup: Yes (dual monitors)
• Display scaling: 100% on both monitors
• Codex version: latest version as of June 5, 2026

Behavior:

• When the Codex window is maximized, the left menu/sidebar becomes transparent and shows the desktop background behind it.
• This happens on both monitors.
• Today it reproduces every time when maximized.

Workaround:

• Disabling “Semi-transparent sidebar” in Settings > Appearance fixes the issue immediately.

This looks related to the maximized-window rendering path when sidebar translucency is enabled.

Update after checking a newer shipped Windows package and the local Settings UI.

I need to correct/clarify the debug-switch part of my earlier comments. The two gpuTearingDebug settings are real shipped toggles, but on my local install they are not visible in Settings, so they should not be treated as normal end-user repro toggles.

Package inspected:

• OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0
• app/resources/app.asar

What I verified from the shipped bundle:

• webview/assets/gpu-tearing-debug-settings-BOMOa5dz.js defines these defaults as off:
• disableBackdropBlur: false
• disableCssMotion: false
• disableScrollFadeMask: false
• disableScrollFadeMaskAnimation: false
• forceOpaqueRendererBackground: false
• webview/assets/general-settings-BtJsdRnp.js contains a GPU Tearing Debug section with toggles labelled:
• Force opaque web background
• Disable backdrop blur
• That section also says the toggles are temporary compositor-isolation toggles and are only active while the debug gate is enabled.
• The General settings component renders this section only behind a feature/debug gate (te("2423536643") in the minified bundle). On my local install the Settings UI does not show GPU Tearing Debug, and the normal settings section list does not include a separate gpu-tearing-debug-settings route.

So these two switches still look like the highest-value maintainer-side bisection points, but I cannot test them as a normal public user because the debug gate is not enabled in my install.

Suggested maintainer-side bisection:

1. Reproduce with Semi-transparent sidebar on and the Codex window maximized.
2. Enable only forceOpaqueRendererBackground. If the transparent/undrawn sidebar/top region disappears, the failure is likely in transparent-window composition / opaque renderer-background handling.
3. Enable only disableBackdropBlur. If that fixes it instead, the failure is more likely in the backdrop-filter / blur composition path.
4. Compare against the known public workaround: Settings -> Appearance -> Semi-transparent sidebar off.

This slightly changes my earlier wording: the debug switches are real shipped toggles, but gated; asking public users to find them in Settings is not currently a reliable repro step.

Update after checking a newer shipped Windows package and the local Settings UI. I need to correct/clarify the debug-switch part of my earlier comments. The two gpuTearingDebug settings are real shipped toggles, but on my local install they are not visible in Settings, so they should not be treated as normal end-user repro toggles. Package inspected: OpenAI.Codex_26.602.3474.0_x64__2p2nqsd0c76g0 app/resources/app.asar What I verified from the shipped bundle: webview/assets/gpu-tearing-debug-settings-BOMOa5dz.js defines these defaults as off: disableBackdropBlur: false disableCssMotion: false disableScrollFadeMask: false disableScrollFadeMaskAnimation: false forceOpaqueRendererBackground: false webview/assets/general-settings-BtJsdRnp.js contains a GPU Tearing Debug section with toggles labelled: Force opaque web background Disable backdrop blur That section also says the toggles are temporary compositor-isolation toggles and are only active while the debug gate is enabled. * The General settings component renders this section only behind a feature/debug gate (te("2423536643") in the minified bundle). On my local install the Settings UI does not show GPU Tearing Debug, and the normal settings section list does not include a separate gpu-tearing-debug-settings route. So these two switches still look like the highest-value maintainer-side bisection points, but I cannot test them as a normal public user because the debug gate is not enabled in my install. Suggested maintainer-side bisection: 1. Reproduce with Semi-transparent sidebar on and the Codex window maximized. 2. Enable only forceOpaqueRendererBackground. If the transparent/undrawn sidebar/top region disappears, the failure is likely in transparent-window composition / opaque renderer-background handling. 3. Enable only disableBackdropBlur. If that fixes it instead, the failure is more likely in the backdrop-filter / blur composition path. 4. Compare against the known public workaround: Settings -> Appearance -> Semi-transparent sidebar off. This slightly changes my earlier wording: the debug switches are real shipped toggles, but gated; asking public users to find them in Settings is not currently a reliable repro step.

Settings -> Appearance -> Semi-transparent sidebar off. this workaround saved me, at least i can use codex as normal for now