[Bug]: Codex thread title generation fails with gpt-6-luna when using ChatGPT account

[protocedvill]

Area

apps/server (Codex provider, thread title generation)

Environment

• T3 Code (local dev)
• Provider: Codex CLI (OpenAI)
• Auth: ChatGPT account

Steps to reproduce

1. Start a new thread with a message that triggers automatic title generation
2. Use Codex with a ChatGPT account

Expected behavior

Title generation uses a model supported by the account or fails gracefully.

Actual behavior

Fails with: "The 'gpt-6-luna' model is not supported when using Codex with a ChatGPT account."

Observed in trace dabe9710bbc13ec7683c43cc182776e1 (CodexTextGeneration.generateThreadTitle / runCodexJson.runCodexCommand). The user message referenced trace ID 902d19edcd12f7982494422162620eb2, but that ID was not found as a local trace span.

Root cause

One-shot text generation defaults may pick gpt-6-luna which is unsupported for ChatGPT-authenticated Codex sessions. Similar to #12651 (model fallback issue).

Suggested fixes

1. For Codex, use a model compatible with ChatGPT accounts for one-shot generation, or derive from instance/default config
2. Surface stdout JSON error when CLI exits non-zero (avoid masking stderr)
3. Make title generation resilient (fallback/skip on failure)

Workaround

Configure an appropriate Codex model for text generation that matches your account type.

Related: #12651, #14321

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @protocedvill for the report and the trace pointer. I confirmed this on current main. A new thread's automatic title asks Codex for gpt-6-luna, and a ChatGPT-authenticated Codex session rejects that slug with the sentence you quoted. The thread itself still starts, but the title stays as the placeholder.

Why it happens

gpt-6-luna is the schema default, not a one-off selection. DEFAULT_TEXT_GENERATION_MODEL in packages/contracts/src/model.ts is "gpt-6-luna" (set by the merged #13115), and an unset textGenerationModelSelection in packages/contracts/src/settings.ts decodes to the codex instance plus that slug. ThreadTitleRegenerationService passes that selection straight into generateThreadTitle, which is the CodexTextGeneration.generateThreadTitle → runCodexJson.runCodexCommand span you saw, and that always appends --model with the resolved slug.

Dispatch doesn't swap out a slug the account can't run. In apps/server/src/textGeneration/CodexTextGeneration.ts, it keeps an exact catalog hit, otherwise a non-custom slug in the same family, otherwise the requested slug unchanged. gpt-5.6-luna isn't a family match, so a missing gpt-6-luna still goes out as --model gpt-6-luna.

With Connect with ChatGPT this always happens. The managed runtime's snapshot only includes list-visible models, and #14321 already found that this catalog omits gpt-6-luna while keeping gpt-6-astra and gpt-5.6-luna. Text generation reads that snapshot (CodexManagedProvider.ts) and then ignores the miss. An existing codex login ChatGPT account can get the same rejection even when model/list still contains gpt-6-luna.

Settings can also show a different model from the one that runs. The picker substitutes a selectable slug when gpt-6-luna isn't available, but the server only rewrites textGenerationModelSelection when the instance is disabled or is ACP Registry (resolveTextGenerationProvider). So the picker can show gpt-6-astra while codex exec still gets gpt-6-luna. That's the same display-versus-dispatch split as #12651, with a different trigger.

Related

• Title failure is already non-fatal: after two retries it logs Thread title generation failed and leaves "New thread". Commit, PR, and branch generation share runCodexJson, so they fail the same way with this selection.
• Preferring stderr over stdout on a non-zero exit is the secondary defect already confirmed on [Bug]: One-shot text generation (commit/PR/branch/title) ignores the provider's configured model and falls back to claude-haiku-4-5, which backend guardrails can block #12651.
• Showing the failure reason in the UI is [Bug]: Thread title and branch-name generation fail silently when the text generation provider is unhealthy #5359, with open PR fix(threads): failed title regeneration now says why #15111.
• This isn't a duplicate of Connect with ChatGPT omits Codex models available through CLI login #14321, which is about which models the picker lists. This one is text generation sending a slug that list won't run.

Likely fix area

A maintainer will decide on the fix direction. One option: when the requested Codex text-generation slug isn't in that instance's snapshot, fall back to a model the snapshot does contain (the instance default, or the first list-visible slug), and keep Luna when the account's catalog has it.

Workaround

In Settings, under text generation, pick a model your account lists. Resetting that setting writes gpt-6-luna back.

[AatmanAJ]

I'd like to take this one. Plan is the fallback from the triage: if the configured Codex text-generation slug isn't in that instance's model snapshot, use a model the snapshot does list (the instance default, otherwise the first list-visible slug), and keep gpt-6-luna whenever the account's catalog has it. Titles, commit messages, PR text, and branch names share runCodexJson, so they all get the fix.