`--model` flag accepted but fails with "model not supported" on ChatGPT accounts
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:
- Auto-strip prefix — Automatically strip
openai-codex/prefix when using ChatGPT account - Validate upfront — Reject provider-prefixed format at parse time with helpful error
- 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-codexnot 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 timegpt-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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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! 💙
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.
Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞
---
<sub>🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.</sub>