CLI: add a /settings page for discoverable terminal preferences

What variant of Codex are you using?

CLI (TUI).

What feature would you like to see?

Add a /settings page for discovering and changing terminal preferences without leaving the conversation or knowing their TOML keys.

My initial use case was disabling the decorative composer stars when redraws interfere with terminal text selection and copying. The existing tui.whimsy = false option addresses the effect; the missing piece is discovering and changing that preference inside the CLI. Notifications, copy-friendly output, and other terminal preferences have the same discoverability problem.

The proposed interaction is:

• A few controls per section: Appearance, Input & copying, Notifications, Conversation, Sessions, and Advanced.
• One list of settings with current values. Up/Down selects a setting, Left/Right changes and saves it, and Tab/Shift+Tab changes sections while remembering the selection.
• The selected setting's explanation appears below the list by default, including whether a change applies immediately, to the next session, or after restarting. Keyboard shortcuts stay at the bottom.
• Unavailable controls are dimmed and explain why when focused. For example, pets and pet positioning are unavailable in tmux. They cannot be activated accidentally.
• Complex choices, such as themes and keyboard shortcuts, open their existing pickers with Enter and return to the settings page.

Example from the working prototype:

Settings · saves automatically
Appearance  Input & copying  [Notifications]  Conversation  Sessions  Advanced

  Notifications   On
› Delivery        ‹ Desktop (OSC 9) ›
  When to notify  When unfocused

Delivery · Applies immediately

Automatic chooses an appropriate terminal notification backend. Desktop uses OSC
9 when supported; Bell uses the terminal bell, whose sound or visual behavior is
controlled by your terminal.

Delivery: Saved. Applies immediately.

Tab / Shift+Tab section · ↑ / ↓ move · ← / → change · esc back · r reset

Changes should preserve unrelated configuration, respect project and command-line overrides, report failed or overridden saves, and offer a reset to the inherited value.

Additional information

I built and tried a reference implementation in a fork: design and implementation, at commit c521281. It covers 23 existing preferences without new config keys or dependencies. The page was exercised locally in Ghostty/tmux; the TUI test suite passed 4,613 tests with six skipped, including 12 added behavior tests and 18 reviewed layout snapshots.

Related problem: #38017 documents selection failures during status animation redraws in GNOME Terminal/VTE. A settings page makes existing workarounds discoverable; it does not itself fix the underlying terminal redraw behavior.

I understand that external code PRs are not accepted, so the fork is offered as a concrete design reference for this feature discussion. Would a grouped TUI settings page fit the planned CLI UX, and which controls would make sense for an initial version?

Start by reading the linked reference implementation at commit c521281 and the related issue #38017, then run the TUI test suite to understand the existing behavior. Done means a grouped /settings page covers an agreed initial set of terminal preferences, preserves unrelated configuration, respects overrides, reports save failures, and supports resetting inherited values.