Feature: Reorganize slash commands into a structured Settings panel with progressive disclosure

What variant of Codex are you using?

CLI (TUI)

What feature would you like to see?

Problem

Currently, all slash commands (/help, /model, /provider, /approval, /reason, /compact, /history, /sessions, /undo, etc.) are presented as a flat, unorganized list in a single place. This creates several usability issues:

1. Overwhelming for new users. The majority of people using Codex CLI are not experienced developers. They don't know how to edit config.toml, set up sub-agents, customize system prompts, or configure MCP servers. What seems obvious to the dev team is deeply non-obvious to first-time users who have no coding background.
2. No discoverability or grouping. There's no logical grouping — session management commands sit next to model configuration commands, next to approval-mode toggles. Users have to memorize or re-read /help every time.
3. Config-file dependency. Many settings (model, provider, approval mode, system prompt, instructions, MCP servers) currently require editing config.toml manually. This is a significant barrier. Users should be able to change these settings directly from within the TUI and have them take effect immediately — without restarting the session or hunting for a TOML file.

Proposed Solution

1. Introduce a /configs panel (or screen) inside the TUI

Instead of scattering configuration across dozens of slash commands, provide a dedicated Settings screen accessible via /configs (or a keybinding like Ctrl+,). This screen would group related options into logical sections:

| Section | What it contains |
|---|---|
| Model & Provider | Model selection, provider, context window, reasoning effort |
| Behavior | Approval mode, auto-edit, notify on complete |
| Prompts & Instructions | System prompt, custom instructions (instructions.md) |
| Agents | Sub-agent configuration |
| MCP Servers | List, add, remove MCP servers |
| Session | History, compact, undo, session management |
| Advanced | Shell, sandbox permissions, file-read permissions |

2. Progressive disclosure

• Level 1 (default view): Show only the most commonly used settings — model, approval mode, provider. This is what a brand-new user needs.
• - Level 2 (expanded): Prompts, instructions, MCP servers — for users who want to customize behavior.
• - - Level 3 (advanced): Shell environment, sandbox networking, file permissions, sub-agents — for power users.

This way, a first-time user sees a clean, simple interface, while a power user can drill down into the full configuration.

3. Live config updates from the TUI

Any setting changed in the /configs panel should be applied immediately to the running session — no restart required. Optionally, offer a "Save to config.toml" toggle so that changes persist across sessions.

4. Keep slash commands as shortcuts

Existing slash commands don't need to be removed — they can remain as quick shortcuts for power users. But they should no longer be the only way to discover and manage settings.

Why This Matters

Codex is being used by a rapidly growing audience, many of whom are not developers. They are writers, designers, students, researchers, and hobbyists exploring AI-assisted coding for the first time. Asking them to:

• find and edit ~/.codex/config.toml
• - understand TOML syntax
• - - know what approval_mode, model_provider, or mcp_servers even means
• - - - restart the session after each config change

...creates unnecessary friction and drives people away from what is otherwise an incredible tool.

A well-organized Settings panel with progressive disclosure would:

• dramatically lower the barrier to entry
• - reduce confusion and support burden (fewer "how do I change the model?" issues)
• - - align with UX best practices used by every major editor and terminal tool (VS Code, iTerm2, Warp, etc.)
• - - - make Codex feel polished and production-ready

Summary

| Current state | Proposed state |
|---|---|
| Flat list of / commands | Grouped, categorized /configs panel |
| Config changes require editing TOML | Config changes from TUI, applied instantly |
| All options visible at once | Progressive disclosure (basic → advanced) |
| Assumes developer knowledge | Accessible to non-technical users |

Additional information

This request is based on real-world experience from non-developer users who find the current slash-command-only approach difficult to navigate. The pattern of progressive disclosure in settings is well-established in tools like VS Code (Settings UI vs. settings.json), iTerm2 (Preferences panels), and Warp (Settings screen). Codex could benefit greatly from a similar approach, especially given its growing non-technical audience.

Happy to discuss implementation ideas or help with UX mockups if that would be useful.