Connector Approvals blocks core's key check, blaming the provider or Gutenberg ("not possible to connect" on Settings → Connectors) #1069

Description

With Connector Approvals enabled, saving an AI provider key on Settings → Connectors can fail with:

It was not possible to connect to the provider using this key.

The key is fine. Core validates it by listing the provider's models (_wp_connectors_is_ai_api_key_valid() → ProviderRegistry::isProviderConfigured()), and Http_Guard blocks that request because Caller_Identifier attributes it to the outermost plugin on the stack. Core turns the resulting WP_Error into the generic message above, so the real cause is invisible in the UI:

The "openrouter" AI connector has not been approved for use by "ai-provider-for-openrouter/ai-provider-for-openrouter.php".

#595 set out to let exactly this through ("requests that originate from WP Core (like authentication of credentials) or requests that filter through a Provider plugin (but don't originate there) are allowed through without approvals"), but two cases still slip:

1. The provider is blamed for its own key check. When a provider's own class sends the request (the OpenRouter provider overrides sendListModelsRequest()), the provider is the only plugin on the stack, so it is taken for the caller. Providers that inherit the request from core's OpenAI-compatible base class (e.g. ai-provider-for-openai) are not affected, because none of their files are on the stack.
2. Gutenberg is blamed. Gutenberg 23.9 through 24.0 ships a polyfill of core's connectors.php (lib/compat/wordpress-7.0/default-connectors.php) that runs the key check in core's place, and only core's connectors.php is in the skip list. The polyfill is gone in Gutenberg 24.1 RC, but 24.0 is the current stable release.

Either way the admin has to discover the pending entry under Tools → AI Connector Approval, while the Connectors screen says the key is wrong. Related: #660 (ambiguous errors when a request is blocked).

Confirmed on develop (8f275a9): every file in includes/Connector_Approval/ is unchanged since 1.3.0.

Step-by-step reproduction instructions

Case 1 (no Gutenberg)

1. Activate the AI plugin and the OpenRouter provider (ai-provider-for-openrouter 1.0.0 from wordpress.org).
2. Enable the Connector Approvals experiment.
3. On Settings → Connectors, save any OpenRouter key.
4. See "It was not possible to connect to the provider using this key." and a pending request for ai-provider-for-openrouter / openrouter under Tools → AI Connector Approval.

The same check from WP-CLI, with a key stored in connectors_ai_openrouter_api_key:

wp eval 'var_dump( _wp_connectors_is_ai_api_key_valid( get_option( "connectors_ai_openrouter_api_key" ), "openrouter" ) ); var_dump( array_keys( get_option( "wpai_connector_approval_pending", array() ) ) );'

bool(false) and a pending ai-provider-for-openrouter/ai-provider-for-openrouter.php::openrouter entry. (OpenRouter's /models endpoint does not authenticate, so the check would return true for any key if the request reached it.)

Case 2 (Gutenberg 24.0 or earlier active)

Same steps with Gutenberg active: the pending request is recorded for gutenberg/gutenberg.php instead, and approving the provider does not help.

Screenshots, screen recording, code snippet

Stack of the blocked request from the Settings → Connectors save (Gutenberg 23.9 active), trimmed:

wp-content/plugins/ai/includes/Logging/Logging_Http_Transporter.php:85
wp-content/plugins/ai-provider-for-openrouter/src/Metadata/OpenRouterModelMetadataDirectory.php:69   <- case 1 blames this
wp-includes/php-ai-client/src/Providers/ApiBasedImplementation/ListModelsApiBasedProviderAvailability.php:45
wp-includes/php-ai-client/src/Providers/ProviderRegistry.php:191
wp-content/plugins/gutenberg/lib/compat/wordpress-7.0/default-connectors.php:411                     <- case 2 blames this
wp-content/plugins/gutenberg/lib/compat/wordpress-7.0/default-connectors.php:537
wp-includes/rest-api/class-wp-rest-server.php:464

Environment info

• WordPress 7.1.2
• AI plugin 1.3.0, and develop at 8f275a9
• AI Provider for OpenRouter 1.0.0
• Gutenberg 23.9.0 (case 2 only)
• PHP 8.3, wp-env

Checklist

• I have searched existing issues in the repo.
• Tested with all plugins deactivated except the AI plugin, apart from the provider plugin the bug needs (and Gutenberg for case 2).
• Theme: not relevant to this server-side check; reproduced on a bare wp-env install with no theme active.