codex - 💡(How to fix) Fix Feature request: runtime activation gating for VPN-backed MCP servers [1 participants]

Summary

Add first-class runtime activation gates for MCP servers so a server can stay configured in config.toml but only load when local runtime conditions indicate it is usable.

Problem

Some MCP servers are only available in specific environments, especially:

• enterprise or internal MCP servers that are only reachable on VPN
• split-DNS-backed MCP endpoints whose hostname only resolves when connected to the right network

Today the practical options are awkward:

• leave the server always configured and accept noisy startup/login failures when the environment does not match
• manually enable and disable the server depending on network context
• keep separate configs for on-VPN and off-VPN situations

That makes VPN-gated MCP servers harder to use than they need to be.

Proposed behavior

Allow an MCP server to remain configured but be excluded from the effective MCP set when activation conditions do not match.

Example config:

[mcp_servers.clearpass]
url = "https://clearpass.example/mcp"
activation = { local_subnets = ["10.1.0.0/16", "fd00::/8"], require_resolvable_host = true }

Suggested activation conditions

• activation.local_subnets Enable the server only when at least one local interface IP falls inside one of the configured CIDR ranges.

• activation.require_resolvable_host = true For streamable HTTP MCP servers, enable the server only when the configured URL host resolves locally.

These conditions should compose with AND semantics when both are present.

Expected UX

When activation does not match:

• the server should remain visible in configured status/list views
• the server should be excluded from the effective loaded MCP set
• manual operations such as MCP OAuth login should fail with a clear disabled reason instead of behaving as if the server is missing

Example disabled reasons:

• activation (no local interface matched any configured subnet: 10.1.0.0/16)
• activation (host clearpass.example was not resolvable)

Why this would help

This would make Codex much easier to use with VPN-backed and enterprise MCP endpoints without forcing users to constantly edit config or accept expected startup failures.

Notes

• hostname resolution should be treated as a runtime availability hint, not a full reachability/health check
• IP-literal hosts should be treated as already resolvable
• non-HTTP transports probably should not support require_resolvable_host