Using /personality reports no support for namespaced model IDs like `openai/gpt-5.3-codex`
What version of Codex CLI is running?
0.105.0
What subscription do you have?
API usage (through internal proxy)
Which model were you using?
openai/gpt-5.3-codex
What platform is your computer?
MacOS (Darwin 25.3.0 arm64 arm)
What terminal emulator and version are you using (if applicable)?
iTerm2
What issue are you seeing?
When I try to use/personality command in Codex CLI, it returns the following error:
Current model (openai/gpt-5.3-codex) doesn't support personalities. Try /model to pick a different model.
This appears incorrect for models with namespace prefix in the name. Personality setting works for bare IDs like gpt-5.3-codex, but fails for namespaced IDs like openai/gpt-5.3-codex. We have to use namespace prefix because of our setup with internal API proxy.
What steps can reproduce the bug?
- Start Codex with model
openai/gpt-5.3-codex. - Run
/personality. - Observe the "doesn't support personalities" error.
What is the expected behavior?
Namespaced IDs (e.g. openai/gpt-5.3-codex) should inherit capability checks from their base slug (gpt-5.3-codex), including personality support.
Additional information
Likely related to namespaced model support introduced in #12658:
ModelsManagernow resolves namespaced IDs by suffix when building model info.- But TUI personality gating still does exact model ID lookup (
preset.model == current_model) before readingsupports_personality.
So capability resolution seems namespace-aware in one path but exact-match-only in another, producing a false negative for /personality.
2 Comments
Why are you specifying the
gpt-5.3-codexmodel with a namespace prefix?Hi, Eric!
We are using internal LiteLLM-based proxy to access OpenAI models (among others) and it has some strict naming conventions for model names, specifically to have prefixes for different model providers in model names - like
openai/gpt-5.3-codexorbedrock/anthropic.claude-sonnet-4-5-20250929-v1:0.I was trying to adjust these naming conventions on our end (which is not easy since there are many dependencies on this naming), but noticed that you recently introduced namespaced model names support in https://github.com/openai/codex/pull/12658 and was hoping it will work across the board of all functionalities.