›_ Codex Issues
Codex Issues / #10622

Model not set when running "Automation" test

Open 💬 3 comments Opened Feb 4, 2026 by benglewis
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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

Version 260203.1501 (523)

What subscription do you have?

Business

What issue are you seeing?

When trying to send follow-up prompts, the "Model" defaults to "" (i.e. just "Medium" is shown).

After you send the prompt:

{"detail":"The '' model is not supported when using Codex with a ChatGPT account."}

What steps can reproduce the bug?

Try running a "Test" of an "Automation"

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

3 Comments

harvitronix · 6 months ago

@benglewis I ran into this, too. It's because the model select is empty when you open an automation thread. Select a model and you can reply.

Seems like a bug though, should choose the previous model used.

etraut-openai contributor · 6 months ago

Thanks for the bug report. I'm able to repro, and it's definitely a bug. We'll look into it.

cusoccerboy · 1 day ago

This is still reproducible in the current Codex desktop app (macOS; Codex Framework 151.0.7922.170), and it can leave an ordinary task unrecoverable—not only an Automation test.

Observed sequence on 2026-08-26:

  1. A normal existing task completed a turn successfully using gpt-5.6-sol.
  2. The app then displayed “Model changed from GPT-5.6 Sol to Custom” and persisted model: "".
  3. The next turn failed immediately with HTTP 400:

The '' model is not supported when using Codex with a ChatGPT account.

Relevant event timing:

  • 13:43:14Z: thread_settings_applied with model: ""
  • 13:43:18Z: turn failed with the 400 error
  • 13:43:56Z–13:43:58Z: valid models were selected again, ending on gpt-5.6-sol

Additional recovery failures:

  • Restarting Codex preserved the failed task and queued items.
  • Selecting a valid model afterward did not repair items labeled “Retry”; retrying retained the failed turn's empty-model snapshot.
  • The task registry reported systemError, but attempting to send a new continuation with gpt-5.6-sol explicitly specified was rejected with: Cannot steer conversation ... without an active turn id.
  • A same-directory fork of the completed history, followed by a new turn explicitly using gpt-5.6-sol, worked. The original task had to be archived.

Expected behavior:

  • The client should never accept or persist an empty model identifier.
  • “Retry” should use the currently selected valid model, or allow the model to be changed for the retry.
  • A task in systemError should accept a fresh continuation rather than trying to steer a nonexistent active turn.
  • The UI should expose the actual backend error instead of remaining at “Thinking.”

I can provide the affected task ID and narrow sanitized JSONL excerpts privately if maintainers need them.