Using /personality reports no support for namespaced model IDs like `openai/gpt-5.3-codex`

Open 💬 2 comments Opened Feb 26, 2026 by mikhail-melnik

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?

  1. Start Codex with model openai/gpt-5.3-codex.
  2. Run /personality.
  3. 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:

  • ModelsManager now resolves namespaced IDs by suffix when building model info.
  • But TUI personality gating still does exact model ID lookup (preset.model == current_model) before reading supports_personality.

So capability resolution seems namespace-aware in one path but exact-match-only in another, producing a false negative for /personality.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗