›_ Codex Issues
Codex Issues / #22466

Plugins unavailable with ChatGPT login and custom model provider using env_key

Open 💬 3 comments Opened May 13, 2026 by qiyuey

Summary

I am using Codex Desktop with ChatGPT login and a custom model provider that uses a separate API key via env_key. Model requests to the custom provider succeed, but plugin discovery / plugin marketplace can still fail or become unavailable.

This looks like a Codex/plugin-discovery issue rather than a model-provider authentication issue: the model provider auth is separated from ChatGPT auth, so Codex should be able to use the custom key for model requests and ChatGPT auth for plugins/connectors.

Environment

  • OS: macOS
  • Codex CLI: codex-cli 0.130.0
  • Codex Desktop: 0.130.0-alpha.5 observed in logs
  • Auth mode: ChatGPT
  • Model provider: custom provider
  • Wire API: responses

Config

model_provider = "cato_company_gpt"
model = "gpt-5.5"

[model_providers.cato_company_gpt]
base_url = "https://model.zhenguanyu.com/v1"
name = "Company Model Platform"
env_key = "MODEL_API_KEY"
wire_api = "responses"

Auth status

$ codex login status
Logged in using ChatGPT

Expected behavior

When using a custom model provider with env_key while also logged in with ChatGPT, Codex should use:

  • MODEL_API_KEY for model requests to the custom model provider
  • ChatGPT auth for plugins, plugin marketplace, connectors, remote plugin sync, and MCP app tools

Plugins should remain available while the active model provider is custom.

Actual behavior

Model requests to the custom provider succeed, but plugin discovery / plugin marketplace can fail. Logs include:

failed to warm featured plugin ids cache
remote plugin sync request to https://chatgpt.com/backend-api/plugins/featured?platform=codex failed with status 403 Forbidden

Directly requesting the same endpoint returns a Cloudflare challenge / 403 instead of JSON, even while codex login status reports ChatGPT auth:

https://chatgpt.com/backend-api/plugins/featured?platform=codex
=> 403 Forbidden
=> content-type: text/html; charset=UTF-8
=> Cloudflare challenge page

Why this seems like a Codex issue

Using env_key successfully separates the custom model provider's authentication from Codex's ChatGPT login. This resolves the earlier failure mode where requires_openai_auth = true caused the custom model provider to receive a ChatGPT token and return 401.

However, after separating model auth from ChatGPT auth, plugin availability still appears to depend on Codex's remote plugin discovery path under chatgpt.com/backend-api/plugins/featured. If this endpoint fails, plugin marketplace / discovery can become unavailable even though:

  • ChatGPT login is active
  • model requests succeed through the custom provider
  • local installed plugin MCP tools may still work if already available/cached

Question

Are Codex plugins officially supported when using a custom model provider with env_key while authenticated with ChatGPT?

If yes, plugin discovery / plugin marketplace should probably continue to work with ChatGPT auth regardless of the active model provider, or degrade gracefully when plugins/featured cannot be warmed.

View original on GitHub ↗

3 Comments

Rafik-Belkadi-Reccap · 2 months ago

+1 Same for me here, not able to use plugins from openai when using a custom provider

snowmy-studio · 25 days ago

I can reproduce this on the current macOS ChatGPT/Codex Desktop with a custom Azure Foundry provider, but without ChatGPT or OpenAI API-key login. This is not a failed catalog fetch: the signed renderer removes the successfully loaded catalog before it reaches the UI.

Environment

  • macOS
  • ChatGPT/Codex Desktop: 26.727.51351
  • bundled Codex CLI: 0.146.0-alpha.9.2
  • model provider: custom azure_foundry
  • provider auth: external command returning a Microsoft Foundry token
  • OpenAI auth: none (codex login status reports Not logged in; no ~/.codex/auth.json)

The effective app-server state is:

account/read = {
  "account": null,
  "requiresOpenaiAuth": false
}

config/read.modelProvider = "azure_foundry"

The official reserved catalog itself loads correctly:

plugin/list:
  openai-curated: 180
  marketplaceLoadErrors: []
  installation policy: AVAILABLE (180/180)

official main/cache HEAD:
  11c74d6ba24d3a6d48f54a194cd00ef3beea18f9

However, the installed signed renderer contains this predicate:

function hti(e) {
  return e !== "chatgpt" &&
         e !== "apikey" &&
         e !== "amazonBedrock"
}

The plugin-directory hook computes:

shouldHideOpenAICuratedMarketplaces =
  hti(Ij(hostId)?.authMethod ?? null)

For this supported custom-provider configuration, authMethod is null, so the predicate returns true. Pni then selects both reserved marketplace names:

openai-curated
openai-curated-remote

and Fni removes them from the plugin/list response before the UI rows are flattened. The observable result is therefore:

app-server: 180/180, no load errors
renderer/UI: 0/180

This also means setting features.plugins=true, features.apps=true, or features.remote_plugin=true cannot fix the problem. Manually adding the reserved marketplace is rejected, and using a renamed/local copy would not be an acceptable substitute for the official catalog.

This overlaps with the renderer path documented in #29478, although that report reaches the hide path through the Statsig gate while authenticated with ChatGPT. Here the decisive input is authMethod=null for a custom provider with requiresOpenaiAuth=false.

Expected behavior

Installation visibility and connector authorization should be separate states:

  1. If plugin/list successfully returns the official catalog with installation=AVAILABLE, the Plugin Directory should display it.
  2. Plugins requiring authorization may request it at ON_INSTALL or ON_USE according to their declared policy.
  3. A custom model provider that does not require OpenAI authentication should not cause the renderer to silently discard the complete official catalog.

Please either:

  • treat requiresOpenaiAuth=false custom-provider sessions as eligible to view/install the catalog; or
  • expose a supported configuration/host capability for catalog visibility that does not require creating an unrelated OpenAI credential.

Could the Codex team confirm whether hiding all openai-curated entries for authMethod=null is intended? If it is not intended, the fix needs to be in the signed Desktop renderer (or a supported host flag), because the backend catalog, manifest, SHA, and installation policies are already valid.

snowmy-studio · 25 days ago

Submitted the same minimal reproduction through the official app-server feedback channel with includeLogs=false (no conversation/log upload). Feedback ID: no-active-thread-019fc5f8-a1b2-70e2-89eb-8e5b2f09bed5.