Expose effective config provenance from the CLI

Problem

Codex now has a fairly rich configuration model: base user config, profile config files, project-local layers, thread/runtime overrides, managed requirements, permission profiles, hooks, MCP/app/plugin settings, and app-server specific configuration paths.

When something behaves differently than expected, users often have to infer the active configuration indirectly from symptoms, logs, or manual file inspection. That makes reports harder to triage and creates avoidable confusion around cases such as:

• profile files being loaded but a specific key not behaving as expected;
• Desktop/App and CLI surfaces appearing to use different config homes or effective values;
• project-local config, hooks, MCP, or skills differing between fresh/resumed sessions;
• settings UI writes or profile migration leaving users unsure which layer currently wins.

There is already strong internal support for this. The app-server config/read API can return the effective config, field origins, and optionally the full config layers. The codex-config loader also tracks origins and layer metadata. However, there does not seem to be a simple user-facing CLI command that prints this information for the same launch context a user is trying to debug.

Related signals

This is not meant to replace the more specific bugs or feature requests below, but several recent issues would be easier to diagnose if users could attach an effective config provenance report:

• #22759: Windows Desktop + WSL config home split-brain; the user cannot easily tell which config home is authoritative.
• #26207: --profile appears to load a profile file while a sandbox-related value does not take effect as expected.
• #25645: profile config appears to duplicate hook discovery/execution, likely because profile activation creates another user layer.
• #20538: Desktop Preferences can get stuck after config write conflicts, leaving the UI and file state hard to reason about.
• #24439: MCP diagnostic gap; that proposal focuses on protocol startup/tool discovery, while this one focuses on config provenance.
• #14133 and #17560: Desktop/resume paths can diverge from the expected effective project or user config.

Proposal

Add a small, read-only command that exposes the same effective configuration information the app-server already computes. Possible names:

codex config inspect
codex config explain

Suggested options:

codex config inspect --json
codex config inspect --cwd /path/to/project
codex config inspect --profile work
codex config inspect --key sandbox_mode
codex config inspect --include-layers

The human output could show:

• Codex home being used.
• Current cwd used for project-local config resolution.
• Selected profile file, if any.
• Effective values for common triage fields: model, provider, approval policy, sandbox/permission profile, hooks, MCP/app/plugin settings, web search, and feature toggles.
• For each printed key, the winning layer/source and file path when available.
• Disabled or ignored layers, with the disabled reason when the loader already knows it.
• A hint when the command is run outside the same cwd/profile as the affected session.

The JSON output could be closer to app-server config/read:

• config
• origins
• layers when requested
• codexHome
• cwd
• selectedProfile
• warnings or diagnostics

MVP scope

• Read-only: no config mutation.
• CLI surface only at first.
• Reuse the existing config loader / ConfigLayerStack origin metadata.
• Support --json for issue reports.
• Support --cwd and --profile so reports can match the affected context.
• Redact or avoid printing secrets and tokens.

Out of scope

• A new config editor UI.
• Running MCP servers or checking tool discovery. That is better covered by #24439.
• Solving every Desktop/App config propagation bug directly.
• Changing config precedence or adding new config layers.

Why this seems useful

This gives users and maintainers a common artifact for config-related issues. Instead of asking users to guess which file or profile is active, maintainers could ask for:

codex config inspect --cwd <project> --profile <name> --json

That should make config, profile, sandbox, hooks, MCP, and Desktop/CLI divergence reports easier to triage while keeping the implementation relatively small because the underlying provenance data already exists.

Open questions

• Should this be a standalone codex config inspect command, a codex doctor --config mode, or both?
• Should the command talk to a running app-server when available so Desktop/App users can inspect the live server context, or should the first version only load config directly from disk?
• Which keys should the human output summarize by default?
• Are there additional fields that must be redacted beyond the existing app-server/config redaction behavior?