[Windows App] Existing conversation fails with HTTP 422 and GPT-5.6 Sol picker renders “High High”

Open 💬 0 comments Opened Jul 19, 2026 by Through100

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

26.715.31925

The installed Windows MSIX package is 26.715.4045.0.

What subscription do you have?

ChatGPT-authenticated account. The exact subscription tier was not available from the local diagnostics.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Two UI failures occurred in the same Codex/ChatGPT Windows desktop app session:

  1. An existing ChatGPT conversation (sanitized title: Iframe Embedding Issue) fails with an HTTP 422 error when it is opened or continued.
  2. After switching the active task to GPT-5.6 Sol with High reasoning, the model-picker trigger renders High High instead of 5.6 Sol High.

Read-only local diagnostics show that the active task's persisted model ID is still gpt-5.6-sol. This suggests that the second symptom is a picker/rendering or state-mapping bug: the reasoning label appears to be substituted for the model label, while the underlying model selection remains correct.

The two symptoms may have separate causes, but they were observed in the same app session and the model-label problem appeared while trying to recover from or work around the conversation failure.

What steps can reproduce the bug?

  1. Launch the current Codex/ChatGPT Windows desktop app.
  2. Open an existing ChatGPT conversation from the conversation list.
  3. Attempt to load or continue that conversation.
  4. Observe an HTTP 422 error surface.
  5. Open the model picker in an active task.
  6. Select GPT-5.6 Sol and High reasoning.
  7. Observe that the picker trigger displays High High.

What is the expected behavior?

  • Existing conversations should load and continue without a 422 response.
  • Selecting GPT-5.6 Sol with High reasoning should display 5.6 Sol High (or the app's equivalent full model-and-effort label).
  • The visible model label should reflect the persisted model ID and should not duplicate the reasoning-effort label.

Additional information

  • Observed on 2026-07-20 in the Pacific/Auckland time zone.
  • Renderer breadcrumbs confirm interaction with the model picker and the visible error surface, but the exact failing endpoint and response body were not retained in the local Codex task history.
  • The existing ChatGPT conversation is not represented as a separate local Codex thread, so its contents could not be inspected through the local Codex thread API.
  • Existing reports were searched before filing. This appears distinct from:
  • #34140, where cloud Project chat listing sends limit=100 and receives a specific 422.
  • #20307, which concerns iframe rendering inside the in-app browser.
  • #19192 and #33098, which concern model selection not applying or reasoning effort resetting.
  • A screenshot or redacted diagnostics can be provided if maintainers need them.
  • Privacy: account identifiers, task/thread IDs, local paths, and conversation contents are intentionally omitted.

View original on GitHub ↗