[Windows][Codex Desktop 26.814.41407] Composer turns bright cyan over RDP; rollback fixes it

Summary

After updating Codex Desktop for Windows on 2026-08-18, the entire composer/input surface became bright cyan, with red/orange text and edge artifacts. The rest of Codex and the rest of the Windows desktop rendered normally.

Rolling back to an older signed Codex package immediately restored normal composer rendering.

Environment

Broken build

• Microsoft Store package: OpenAI.Codex 26.814.5167.0
• Codex Desktop app build: 26.814.41407
• Electron dependency: 42.3.0
• Chromium process annotation: 151.0.7922.137

Working rollback

• Package: OpenAI.Codex 26.721.11231.0
• Codex Desktop app build: 26.721.81911
• Electron dependency: 42.3.0

System

• Windows 11 Enterprise 10.0.26200 (build 26200)
• Session: Windows Remote Desktop / RDP
• Display adapter: Microsoft Remote Display Adapter 10.0.26100.8521
• Fallback adapter: Microsoft Basic Display Adapter 10.0.26100.1
• Virtual screen: 1920x1080
• Renderer device scale factor observed: 1

Steps to reproduce

1. Run the older 26.721.81911 desktop build over the same RDP session. The composer renders normally.
2. Update Codex Desktop to package 26.814.5167.0 / app build 26.814.41407.
3. Launch Codex and open any task.
4. Observe that only the composer/input surface becomes solid bright cyan. Composer text/icons show red/orange artifacts, while the sidebar, task content, other apps, and desktop colors remain normal.
5. Clear the Codex GPU/shader/code caches, re-register the AppX package, and relaunch. The issue persists.
6. Remove the new package and install the older signed package 26.721.11231.0. The issue disappears immediately.

Actual behavior

• Composer background is dominated by exact pixel color #00FFFF.
• Text/icon edges in the composer show red/orange channel artifacts.
• The failure is isolated to the composer surface.
• It occurs consistently across tasks in the affected build.

Expected behavior

The composer should render with the configured/default surface color and normal text colors, including inside a Windows RDP session.

Diagnostics

• A screenshot captured locally inside Windows with Graphics.CopyFromScreen contains the same cyan corruption. This rules out RDP network encoding as the sole cause; the incorrect pixels already exist in the locally composed frame.
• Pixel sampling of the composer crop shows #00FFFF as the dominant color.
• RDP transport was healthy during reproduction: roughly 1 ms RTT, zero packet loss/retransmission, quality 100.
• Clearing 8 Codex cache directories (about 206 MB total), AppX re-registration, and restart did not change the result.
• No persisted Codex appearance override matching cyan was found. The abnormal color is not the app's normal default accent/background.
• The affected renderer processes already contained --disable-gpu-compositing, while an Electron GPU/Viz process was still present.
• Both the working and broken builds declare Electron 42.3.0, so this does not appear to be solely an Electron major-version change.

Composer implementation difference

The broken build contains a new composer surface implementation with translucent color mixing and backdrop filtering, including rules equivalent to:

--composer-layout-surface-background:
  color-mix(in oklab, var(--color-background-primary-soft) 90%, transparent);

--composer-layout-surface-backdrop-filter:
  blur(var(--blur-lg));

background-color: var(--composer-layout-surface-background);
backdrop-filter: var(--composer-layout-surface-backdrop-filter, none);

The working 26.721.81911 app bundle does not contain these composer layout identifiers/rules. The composer controller resources were also substantially refactored between the two builds.

This makes the new translucent/backdrop-filter composer layer interacting with the Windows/RDP compositor the leading suspect.

Workaround

Rollback from app build 26.814.41407 to 26.721.81911.

Related issues

• #24561 — bright cyan/light-blue composer layer during a compositor failure on macOS
• #20413 — Windows stale repaint/compositor issue fixed by disabling GPU/DirectComposition
• #18341 — persistent blurred/translucent overlay below the composer

This Windows case is different because it starts immediately after upgrading to 26.814.41407, occurs without a WebGL preview, is confined to the newly styled composer surface, and is fully resolved by rolling back the app build.

A screenshot showing the affected composer is available and can be added if needed.