config.toml keys set almost all of Codex's persistent behavior, and they are more conveniently understood by group than as a flat list. A dynamic named segment in key paths is denoted as <name> - for example, for a permission profile or an MCP server. An important reference caveat: many keys are experimental, enterprise-only or surface-specific, and a key's presence in the schema is not a recommendation to enable it. The full and exact set for your version is in the official Configuration Reference.

The model, permission and sandbox keys are the core of behavior. The model is set via model, model_reasoning_effort and personality; permissions via default_permissions and the [permissions.<name>] sections with filesystem and network; approvals via approval_policy and approvals_reviewer; the sandbox via sandbox_mode and [sandbox_workspace_write] with network_access and web_search. It is these keys that determine what the agent does without asking and what it can touch at all, so they are edited especially consciously.

The extension and interface keys attach components and configure the look. MCP is set by [mcp_servers.<name>] sections with url, timeouts and tool policy; subagents and roles by the [agents] section; hooks by the [hooks] section and the hooks.json file; the interface by the [tui] section with the status line and keymap. requirements.toml stands apart: it is not an ordinary layer but admin-enforced constraints that lower layers cannot override.

It helps to gather the key groups into a table once. Below is a map from the model to the interface and managed policy. It is worth using the reference with a general caveat: a key's presence does not mean advice to enable it, and rare fields - especially with experimental, dangerously or bypass in meaning - are checked against the linked reference page before use. The schema is verified against /debug-config and the official documentation rather than relying on memory of a key.