dwm.exe handle leak in RDP session while codex exec workers are active (Windows 10 22H2)

Environment

• codex CLI 0.148.0-alpha.9 (Windows)
• Windows 10 Pro 22H2, build 19045.6456
• Session type: RDP — the leak accumulates in the RDP session's dwm.exe; other sessions' dwm instances stay flat
• GPU: NVIDIA discrete GPU + Microsoft Remote Display Adapter

Setup

• An automation script launches up to 10 codex exec --ephemeral --json --output-schema ... workers with CREATE_NO_WINDOW and below-normal priority.
• Each worker runs a long (~25 min) batch that makes heavy use of the built-in image/vision tool and periodically executes PowerShell commands; on 0.148.0-alpha.9 each command spawns codex-command-runner / sandbox helper / conhost processes.

Symptom

• While the worker fleet is active, the session's dwm.exe handle count grows steadily at +80–160 handles/min (working set ~+1.2 MB/min).
• After a few hours: 20,000+ handles, 500+ MB working set, DWM CPU ~17%, and a visible session-wide slowdown.
• Growth stops when the fleet is idle. A session re-login resets dwm and the cycle repeats.

Investigation

• A SetWinEventHook(EVENT_OBJECT_SHOW) trace shows ~40–70 transient top-level windows per minute being shown and destroyed within <20 ms while workers are active. dwm handle steps of +2 correlate 1:1 with these SHOW events (46/47 and 64/82 steps within 0–300 ms in separate runs).
• The windows die before out-of-context hook delivery, so GetWindowThreadProcessId/OpenThread both fail at that point. Cross-referencing the event thread IDs against whole-system thread snapshots taken every 0.5 s attributes all of them (52/52 in a 45 s window) to the session's csrss.exe — i.e. they appear to be OS-side (ghost-window-like) machinery triggered by the workload, not windows created by codex directly.
• Controlled experiments: mass-spawning hidden console processes (cmd/powershell with CREATE_NO_WINDOW, 20–40 each) leaks ≈0 dwm handles per process, so plain conhost churn is not sufficient to reproduce. Suspending cloud-sync/screenshot utilities for 45 s each does not stop the leak; stopping the codex fleet does.
• Reducing per-batch shell command count on our side cut process churn from ~86 to ~18 processes/min, but the leak persisted at ~+94–149/min while batches were active — the trigger seems tied to worker activity itself (vision/API loop), not only process spawns.

Possibly related

• #33776 (DWM handle growth / conhost accumulation with codex on Windows 10 22H2)

Ask

Any insight into what in the exec worker loop could trigger csrss transient-window creation in Win10 RDP sessions (e.g. an unpumped hidden window tripping the hung-window ghosting path)? A CLI-level fix or workaround would remove the need for periodic session re-logins.

Workarounds we currently use

• Fewer shell commands per batch (prompt-side batching)
• Scratch/temp files moved off cloud-synced folders (removes an unrelated second trigger)
• Periodic RDP session re-login to reclaim dwm handles

No source file or test is named. Start at the codex exec --ephemeral worker entry point and reproduce the leak in a Windows 10 22H2 RDP session with image work and periodic PowerShell commands. Correlate worker activity with csrss transient-window events and DWM handles; done means identifying a reproducible trigger and validating a CLI fix or reliable workaround.