App-server: expose managed integration policy before optional startup

What variant of Codex are you using?

Codex CLI / app-server on Windows 11. The behavior was traced against CLI 0.151.0 (rust-v0.151.0, commit 78c290807ce710180111df227df3b7a4fe845452). The consumer is non-interactive repository review automation using the maintained CLI, not a replacement model host.

What feature would you like to see?

Please add a supported, invocation-scoped way to inspect and bind the complete effective integration policy before app-server or exec starts optional plugin, marketplace, remote-control, MCP discovery, or MCP transport work.

The surface could be a metadata-only CLI command, a pre-start handshake mode, or an equivalent supported API. It should:

1. Load the same authoritative local, project, managed/MDM, and authenticated cloud-policy layers that the eventual invocation will use.
2. Return redacted structured metadata sufficient to decide admission: exact effective MCP and plugin identities, enabled state, required/locked policy, normalized feature pins (including plugins/apps), and whether any optional startup is required by policy.
3. Guarantee that optional marketplace Git sync, remote plugin bundle fetch, persisted remote-control startup, MCP OAuth/auth discovery, and MCP transport startup have not occurred before that result. Necessary Codex authentication and managed-policy retrieval can remain explicit control-plane activity; this is not a request for an offline reviewer.
4. Fail before optional startup when managed policy conflicts with a caller's local-only integration boundary. Managed requirements must not be overridden merely to make the check pass.
5. Let the caller bind the inspected configuration to the subsequent exec/review launch (for example with an opaque config/policy digest or an atomic inspect-and-run mode), so policy cannot change between admission and execution.
6. Work through the normal npm launcher and one-off CLI overrides without modifying global configuration, copying credentials, disabling authentication, changing model/effort, or using internal environment markers.

The intended fail-closed flow is: inspect authoritative policy without optional integration startup; reject required/unknown integrations; derive invocation-only disables for every optional integration; verify the exact effective launch configuration; then start the unchanged requested model operation.

Additional information

Current public surfaces cannot establish this boundary:

• Official documentation says configRequirements/read returns managed configuration, allowlists, pinned feature requirements, and network requirements. But a client reaches it only after app-server initialization, while app-server constructs the message processor and schedules plugin startup tasks during startup (0.151.0 source). A post-start refusal cannot prove that optional startup never happened.
• codex mcp list --json has no policy-only mode. It builds effective servers and computes auth statuses before rendering JSON (source); for enabled HTTP servers that can include optional OAuth metadata discovery. Its JSON also does not expose complete required-policy metadata.
• codex plugin list --json is useful local inventory, but is not a complete authoritative pre-start view of managed/remote requirements. Passing features.plugins=false makes the view empty, so an empty post-disable inventory is not evidence of identity stability.
• codex features list reports feature name/stage/enabled, not complete integration identities or requirement provenance. Managed feature normalization can apply pinned values before runtime config is constructed (source), so a CLI features.plugins=false override cannot be assumed to defeat a managed requirement.
• app-server --strict-config rejects unknown config fields; it does not freeze optional startup or provide a pre-start policy receipt.

A useful acceptance test would configure a synthetic local stdio MCP sentinel outside the user config and assert that metadata-only inspection reports it without starting it; an enabled/required managed case should fail admission before the sentinel or any optional startup runs. The same fixture can verify that the subsequent bound launch uses the inspected identity set and that removing the guard makes the sentinel start. No model request or real provider/VPS integration is needed for that test.

Related but distinct issues:

• #17622 demonstrates plugin startup Git/SSH work occurring without an explicit user action.
• #39682 documents remote plugin download/initialization despite a narrower remote-plugin feature setting.
• #38401 describes the existing marketplace auto-upgrade startup behavior.

Those issues concern particular startup effects or update behavior. This request is for a general supported admission contract for automation that must preserve managed policy while proving optional integrations have not started.

Start with codex-rs/app-server/src/message_processor.rs, codex-rs/cli/src/mcp_cmd.rs, and codex-rs/core/src/config/managed_features.rs to understand current startup and policy handling. Use the proposed synthetic local stdio MCP sentinel acceptance test as the boundary: inspection should report effective policy without starting optional integrations, and a bound launch should preserve that identity set.