Personality "none" doesn't work anymore

I checked current main, and the backend path appears to preserve an explicit personality = "none" value.

Personality::None is a valid lowercase config value, explicit none is forwarded as "none" in config overrides, and model instruction generation maps Personality::None to an empty personality message. So this does not look like a config parsing or instruction-generation issue.

The mismatch looks likely to be in the UI selection surface. One concrete path is codex-rs/tui/src/chatwidget/settings_popups.rs: the personality picker currently only builds items for Friendly and Pragmatic, even though label/description text for None already exists. A small fix there would be to include Personality::None in the picker and update the personality popup snapshot.

One caveat: #22780 is already touching personality feature gating and explicitly says users should be able to opt out with none, so this may be better folded into that work if the PR is still active rather than sent as a standalone unsolicited PR.

Then it doesn't factor it in i guess because i keep getting those retarded "You’re right to push on that", "Nice catch!", "I shouldn't have done that", "Good push back", etc. it's so frustrating.

I want to add a power-user use case for why this matters beyond the UI mismatch.

personality = "none" is a real config value in the CLI that codex accepts. On my install, invalid values are rejected with:

unknown variant `bogus`, expected one of `none`, `friendly`, `pragmatic`
in `personality`

Please expose personality = "none" in the Codex Desktop/CLI UI and preserve it when settings are changed.

AGENTS.md should be able to serve as the user-defined role/persona layer. Preset personalities are useful, but they shouldn’t be mandatory.

Confirmed this regression still exists in the current macOS Desktop release 26.727.51351 (build 6119), which is the newest build in the published Sparkle appcast as of 2026-08-03.

Reproduction

1. Set personality = "none" in a trusted project .codex/config.toml (the runtime accepts the value).
2. Fully restart Codex Desktop.
3. Open Settings → Personalization.
4. The selector offers only Friendly and Pragmatic and displays Friendly.
5. Create a brand-new task in that project.
6. Its first session turn_context records personality: "friendly", not none.

Localization

Read-only inspection of the installed release bundle shows the Desktop frontend narrows the enum before using it:

function isDesktopPersonality(value) {
  return value === "friendly" || value === "pragmatic";
}

The Personalization component also constructs only the Friendly and Pragmatic option records and visually falls back to the first option for any unlisted value. A separate status renderer treats every non-Friendly value as Pragmatic. The underlying app-server/runtime still accepts none, so this is a Desktop frontend mismatch rather than a runtime/config-schema limitation.

Documentation conflict

The current official docs say Desktop Settings should offer Friendly, Pragmatic, or None, and the config reference documents none | friendly | pragmatic:

• https://learn.chatgpt.com/docs/reference/settings#personalization
• https://learn.chatgpt.com/docs/config-file/config-reference

Expected fix / regression test

• Add none to the Desktop validator and Personalization selector.
• Add a truthful None label/description and status rendering.
• Preserve an existing personality = "none" value rather than falling back to Friendly.
• Verify Settings selection persists across quit/relaunch.
• Verify a newly created task records turn_context.personality == "none".
• Verify Friendly → Pragmatic → None switching remains truthful in Settings and task status.

This is not fixed by adding the config line alone because the current Desktop frontend filters none out before falling back to Friendly.