`--model` flag accepted but fails with "model not supported" on ChatGPT accounts

Open 💬 3 comments Opened Feb 20, 2026 by DylanOpet
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

When using ChatGPT account authentication, the --model flag rejects provider-prefixed model names (e.g., openai-codex/gpt-5.1-codex) but accepts bare model names (e.g., gpt-5.1-codex).

The CLI accepts the provider-prefixed format at startup but fails during execution with:

ERROR: {"detail":"The 'openai-codex/gpt-5.1-codex' model is not supported when using Codex with a ChatGPT account."}

Steps to Reproduce

Environment: Codex CLI v0.104.0 with ChatGPT account authentication

# Fails: provider-prefixed format
codex exec --model openai-codex/gpt-5.1-codex "Say hello"

# Works: bare model name
codex exec --model gpt-5.1-codex "Say hello"

Expected Behavior

One of:

  1. Auto-strip prefix — Automatically strip openai-codex/ prefix when using ChatGPT account
  2. Validate upfront — Reject provider-prefixed format at parse time with helpful error
  3. Document — Clearly state that ChatGPT accounts must use bare model names (no provider prefix)

Actual Behavior

With provider prefix (openai-codex/gpt-5.1-codex):

  • ✅ CLI accepts flag
  • ✅ Session initializes
  • ⚠️ Warning: "Model metadata for openai-codex/gpt-5.1-codex not found"
  • ❌ Execution fails: "model is not supported when using Codex with a ChatGPT account"

Without prefix (gpt-5.1-codex):

  • ✅ Works perfectly

Output Comparison

FAILS:

$ codex exec --model openai-codex/gpt-5.1-codex "Say hello"
OpenAI Codex v0.104.0 (research preview)
--------
model: openai-codex/gpt-5.1-codex
provider: openai
--------
user
Say hello
mcp startup: no servers
warning: Model metadata for `openai-codex/gpt-5.1-codex` not found.
ERROR: {"detail":"The 'openai-codex/gpt-5.1-codex' model is not supported when using Codex with a ChatGPT account."}

WORKS:

$ codex exec --model gpt-5.1-codex "Say hello"
OpenAI Codex v0.104.0 (research preview)
--------
model: gpt-5.1-codex
provider: openai
--------
user
Say hello
mcp startup: no servers
thinking
**Preparing simple greeting response**
codex
Hi there!
tokens used 907

Impact

  • Confusing UX — Provider prefix accepted at parse time but rejected at execution
  • Unclear error — Error message doesn't mention the prefix issue
  • Undocumented limitation — No documentation about bare-name requirement for ChatGPT accounts
  • Breaks automation — Tools programmatically using provider-prefix format fail unexpectedly

Use Case

This affects agent orchestration tools (e.g., OpenClaw) that use provider-prefixed model names for clarity and consistency across multiple providers. The openai-codex/ prefix is a natural way to namespace models but silently fails on ChatGPT accounts.

Proposed Fix

Option 1 (Recommended): Auto-strip prefix for ChatGPT accounts:

if (authType === 'chatgpt' && args.model?.startsWith('openai-codex/')) {
  args.model = args.model.replace('openai-codex/', '');
  console.log(`Note: Stripped 'openai-codex/' prefix (ChatGPT accounts use bare model names)`);
}

Option 2: Validate upfront:

if (authType === 'chatgpt' && args.model?.includes('/')) {
  console.error('Error: ChatGPT accounts require bare model names (e.g., "gpt-5.1-codex")');
  console.error('Remove the provider prefix and try again');
  process.exit(1);
}

Option 3: Update documentation and help text to clarify this requirement.

Environment

  • Codex CLI: v0.104.0
  • Auth: ChatGPT account (confirmed via codex login status)
  • OS: macOS Darwin 25.2.0 (arm64)
  • Node: v25.5.0

Verification

Tested both formats with identical prompts:

  • openai-codex/gpt-5.1-codex → fails every time
  • gpt-5.1-codex → works every time

Same behavior across multiple OpenAI model names.

---

Root cause: ChatGPT account validation doesn't recognize provider-prefixed model names, but the CLI doesn't strip the prefix or reject it upfront.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 6 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #12235
  • #11684
  • #10396

Powered by Codex Action

DylanOpet · 6 months ago

Hey! Just reviewed the suggested duplicates but it appears different.

What I discovered:
Provider-prefixed model names are getting rejected on ChatGPT accounts, but bare names work fine:

❌ codex exec --model openai-codex/gpt-5.1-codex "Say hello" → ERROR
✅ codex exec --model gpt-5.1-codex "Say hello" → SUCCESS

Same model, same account, same CLI version, the only difference is that openai-codex/ prefix.

How this differs from the suggested issues:
#12235 is about exec vs interactive mode
#11684 is account type detection
#10396 is about o3 via MCP

None of them caught the provider-prefix format issue specifically.

My test results:
Auth confirmed: ChatGPT account via codex login status
✅ gpt-5.3-codex → worked perfectly (921 tokens)
✅ gpt-5.1-codex → worked perfectly (907 tokens)
❌ openai-codex/gpt-5.1-codex → immediate fail with "not supported when using Codex with a ChatGPT account"

The prefix format just... seems like it's not being handled for ChatGPT auth? I don't primarily use this feature myself, but I caught wind from others on X saying they were suddenly getting "ghosted" by their orchestrator when spawning sub-agents (which is what OpenClaw does). So I started digging deeper and this is what I found. Not 100% sure if it's the root cause, but it lines up with what people were reporting.

Thanks for taking a look! 💙

sstklen · 6 months ago

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: ChatGPT API receives raw provider-prefixed model string (e.g. openai-codex/gpt-5.1-codex) without stripping the prefix. The CLI validates the flag at parse time but never normalizes it before the API call, so the prefix passes through verbatim to an endpoint that only accepts bare model names.

What worked for us:

In the model resolution path (where the --model value is prepared for the API request), detect ChatGPT account auth and strip any provider prefix (everything before and including the first '/') from the model name. Add this normalization before the API call, not at CLI arg parsing, so that internal routing/logging can still see the original qualified name.

// In the function that resolves the model name for API calls (e.g. resolveModel or buildRequestConfig):

function normalizeModelForChatGPT(model: string, isChatGPTAccount: boolean): string {
  if (isChatGPTAccount && model.includes('/')) {
    // ChatGPT accounts only accept bare model names (e.g. 'gpt-5.1-codex')
    // Strip provider prefix like 'openai-codex/' 
    return model.split('/').pop()!;
  }
  return model;
}

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

_Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying._

---
<sub>🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.</sub>