[Windows App] Existing conversation fails with HTTP 422 and GPT-5.6 Sol picker renders “High High”
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:
- An existing ChatGPT conversation (sanitized title:
Iframe Embedding Issue) fails with an HTTP422error when it is opened or continued. - After switching the active task to
GPT-5.6 Solwith High reasoning, the model-picker trigger rendersHigh Highinstead of5.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?
- Launch the current Codex/ChatGPT Windows desktop app.
- Open an existing ChatGPT conversation from the conversation list.
- Attempt to load or continue that conversation.
- Observe an HTTP
422error surface. - Open the model picker in an active task.
- Select
GPT-5.6 Soland High reasoning. - Observe that the picker trigger displays
High High.
What is the expected behavior?
- Existing conversations should load and continue without a
422response. - 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=100and receives a specific422. - #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.