[App] Make supported config.toml options discoverable in Advanced settings

What variant of Codex are you using?

Codex App / Desktop.

What feature would you like to see?

Add an Advanced settings section at the bottom of the existing Settings → Configuration page. It should expose supported, user-editable config.toml options that do not already have a control elsewhere in Codex.

| | |
| --- | --- |
| Status | Proposal only; this does not alter the shipped app |
| Surface | Codex Desktop → Settings → Configuration |
| Scope | Supported user config.toml settings without an existing app control |
| Ready-to-port commit | e81ced66 |

Decision requested

Would maintainers accept this product and classification contract for the private Desktop implementation?

• Accept: invite or port the implementation in the Desktop source tree.
• Adjust: identify the eligibility rule, control behavior, naming, or scope to change.
• Decline: close the proposal without requiring an implementation review.

The Electron Desktop source is not present in the public repository. The draft PR attempt was rejected by the upstream CreatePullRequest permission gate, so this issue is the reviewer-ready decision artifact.

Proposed settings UI

!Concept for Advanced settings at the bottom of Codex Desktop Configuration

Read the complete proposal, behavior matrix, implementation sketch, and test plan.

The concept deliberately reuses the existing Configuration page, card rows, switches, selects, number fields, dividers, and search behavior. It does not introduce a second Advanced settings destination.

No-duplicate contract

Every supported schema key must resolve to exactly one disposition:

1. Advanced control: render the curated typed control.
2. Existing control: do not render a duplicate; link to the current setting when useful.
3. Dedicated surface: route complex objects such as MCP servers, model providers, agents, plugins, and hooks to their purpose-built UI.
4. Excluded: record a reason for secrets, credentials, deprecated aliases, internal keys, or unsafe/unsupported behavior.

A completeness test should fail when a newly supported schema key has no disposition. This prevents both duplicate controls and quiet discoverability drift.

Duplicate search

Open and closed issues and pull requests were searched on 2026-08-11 for advanced settings, config.toml settings, config.toml GUI, settings UI, and related Desktop configuration terms. No exact umbrella request was found.

Closest related requests:

• #32220 requests dedicated MCP configuration/authentication UI.
• #35548 requests per-tool MCP permissions and metrics.
• #26255 requests a read-only CLI config-provenance command.
• #2760 requested configuration documentation and is closed.
• #23499 requests a dedicated Plugins view.
• #24961 proposes a new project-local config layer.

This proposal does not duplicate those surfaces or change config precedence. If maintainers identify a broader canonical issue, please consolidate this proposal there rather than creating a parallel implementation lane.

Behavior contract

| Config state | Advanced settings behavior |
| --- | --- |
| Existing app control | Do not render a duplicate |
| Supported, stable, user-editable key | Render the registry-defined typed control |
| Default or inherited value | Show the effective value and source without writing |
| Explicit user value | Show it as overridden and offer Reset |
| Managed requirement | Show the effective value read-only and identify it as managed |
| CLI-only or OS-specific | Label or conditionally render it accurately |
| Invalid input or failed write | Preserve the prior value and show an inline error |
| External version conflict | Refresh and ask the user to retry; never overwrite silently |
| Reset | Remove the user override rather than writing a guessed default |

Initial controls demonstrated in the concept cover writable roots, temporary-directory access, login-shell behavior, terminal polling, tool-output limits, project discovery, history/compaction, and selected CLI-only TUI options.

Existing implementation seam

The public app-server already provides:

• config/read for effective values and layers,
• configRequirements/read for managed requirements,
• config/value/write for one user-config key, and
• config/batchWrite for atomic multi-key edits.

Those paths already reject managed writes, non-user config paths, and stale expected versions. The missing work belongs in the private Desktop UI: curated metadata, typed controls, validation, source labels, and tests. No speculative generic config RPC is proposed.

Acceptance criteria

• No option already exposed elsewhere in Codex is duplicated.
• Every supported schema key has exactly one disposition.
• Typed controls round-trip through the existing config RPCs.
• Inverse booleans such as exclude_slash_tmp are encoded correctly.
• Missing values show defaults/inheritance without writing to disk.
• Reset removes only the selected override.
• Managed values remain attributed and read-only.
• Stale writes never overwrite external edits.
• Search matches both friendly labels and exact TOML keys.
• CLI-only, OS-specific, and reload/restart behavior is labeled accurately.
• Keyboard navigation and screen-reader behavior match the existing settings UI.

Risk controls and non-goals

• No raw TOML form generator.
• No secrets, credentials, generic provider tables, or MCP tables.
• No change to config precedence or addition of config layers.
• No undocumented operating-system preferences that weaken Computer Use protected-target safeguards; those require separate private product/security review.
• Opening Advanced settings writes nothing, and editing one key preserves unrelated config.