codex - 💡(How to fix) Fix Windows Codex app XHigh verification quality degraded for native WinUI UI fixes

What version of the Codex App are you using (From “About Codex” dialog)?

26.506.31421

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0

What issue are you seeing?

I am seeing noticeably degraded XHigh Codex behavior on Windows during native WinUI app work.

The model repeatedly reported UI issues as fixed based on tests/static checks, but the actual running WinUI app still showed obvious visual/runtime issues. This happened during a fresh WinUI 3 project where Codex was asked to build and refine a simple Lead Intake screen.

Examples:

1. Codex claimed the Lead Intake empty-state event date/time issue was resolved, but the running app still visually showed “7/9/2026 4:00 PM”. A later pass found the root cause was simply a XAML PlaceholderText value in MainWindow.xaml, not view model state.
2. Codex claimed compact date normalization worked, but in the actual running app typing “05242026” into the Event date/time field and moving focus to another field did not update the displayed field to “05/24/2026”.
3. Codex attempted a visual/screenshot smoke check on Windows, but captured the Codex window itself instead of the launched WinUI app, so the visual verification was inconclusive.

The code often built and tests passed, but the model seemed to rely on test-path verification and missed real UI behavior in the running app. This felt significantly worse than prior XHigh Codex sessions on similar native Windows app work.

What steps can reproduce the bug?

Uploaded thread: c9314bc8-0636-4f26-8756-90681e6c3c891. Use Codex on Windows with XHigh reasoning on a native WinUI 3 app. 2. Ask it to implement or refine a form-based UI with XAML bindings, TextBox fields, and view model validation. 3. Ask it to verify that the running UI behavior matches the requested behavior. 4. Example issue: ask it to normalize compact date input such as “05242026” to “05/24/2026” on focus loss / validation / create. 5. Run the app manually in Visual Studio. 6. Type “05242026” into the Event date/time field. 7. Move focus to another field. 8. Observe that the field still displays “05242026” even though Codex claimed normalization was implemented and verified. 9. In a separate case, ask Codex to visually verify the WinUI app. It may produce a screenshot artifact, but it captured the Codex window instead of the launched app.

What is the expected behavior?

Codex should not claim UI behavior is fixed unless the relevant runtime path is actually wired and verified.

For native Windows UI work:

• If it cannot visually verify the app, it should say so clearly.
• If a screenshot does not show the target app/window, it should mark the visual check as inconclusive.
• Tests should cover the actual view model / binding / focus-loss path when the bug is UI behavior.
• XHigh should reliably find simple XAML causes such as sample PlaceholderText values before claiming a state bug is fixed.

Additional information

This occurred during the same period OpenAI status showed GPT-5.5 / Codex degradation. I also submitted in-app feedback with current Codex session logs included.

This is not a request for broad Windows Computer Use. The main issue is verification quality: Codex should avoid claiming runtime UI verification succeeded unless it actually verified the target app state.