app-server: turn/start accepts a model+reasoningEffort pair the model catalog says is unsupported, then hangs with zero events

[Caleb0796]

Environment

codex-cli 0.142.4, macOS (darwin 25.5), app-server protocol via stdio.

Repro

1. Model catalog (codex debug models) says gpt-5.4-mini supports reasoning levels low/medium/high/xhigh only (max/ultra are 5.6-family tiers).
2. Through app-server: thread/start (resolves/echoes the model), then turn/start with { model: "gpt-5.4-mini", effort: "ultra", input: <trivial one-line prompt> }.

Observed

• turn/start is accepted: thread created for gpt-5.4-mini (task_started event, model_context_window: 258400).
• Then zero further events: no error event, no items, nothing — observed for 7+ minutes on a prompt whose normal round-trip is seconds. The session rollout (~/.codex/sessions/.../rollout-*.jsonl) contains only task_started.
• Callers with no client-side timeout block forever; the turn had to be interrupted manually (turn/interrupt worked fine).

Same class is reachable for every value the catalog does not list for the resolved model (e.g. none/minimal, which no current catalog model advertises).

Expected

turn/start (or the turn itself, as a prompt error event) should fail fast with something like: model "gpt-5.4-mini" does not support reasoning effort "ultra"; supported: low, medium, high, xhigh — the server has the catalog and the resolved model at that point.

Impact / context

Found while adding max/ultra support to the Claude Code companion plugin (openai/codex-plugin-cc#454): any client that forwards an unsupported effort gets a silent indefinite hang instead of a validation error, which turns a one-keystroke user mistake into a stuck background job. We are adding client-side catalog validation as a workaround, but the authoritative check belongs server-side.

Thread/turn ids from the captured repro available on request: thread 019f40e8-136e-7c41-a4e9-04f53f73ef98, turn 019f40e8-20af-7762-b2b3-3847478a6f9c.

🤖 Generated with Claude Code