MCP servers disappear from session when using a custom provider

Open 💬 2 comments Opened Apr 24, 2026 by ForeverInLaw

What version of Codex CLI is running?

codex-cli 0.124.0

What subscription do you have?

Business

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.8.0-106-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

bash over SSH on a Linux server

What issue are you seeing?

MCP servers are configured and visible to Codex via codex mcp list, but they disappear from the actual session when using a custom provider

In my setup:

  • codex mcp list shows context7
  • codex mcp get context7 shows it as enabled with the expected URL and headers
  • with the native provider, Context7 is available in-session
  • with the custom provider, the session starts, but MCP discovery inside the session returns no resources and no resource templates

Example session output:

user
  check if context7 is available in mcp tools in your session
codex
  I’m checking the configured MCP servers and exposed resources/templates in this session to see whether `Context7` is actually available.
  mcp: codex/list_mcp_resources started
  mcp: codex/list_mcp_resource_templates started
  mcp: codex/list_mcp_resources (completed)
  mcp: codex/list_mcp_resource_templates (completed)
codex
  `Context7` is not available in this session’s MCP tooling.

  I checked the active MCP surface and found:
  - no MCP resources
  - no MCP resource templates
  - no `Context7`-specific tools such as `resolve-library-id` or `get-library-docs`

At the same time, outside the session:

  $ codex mcp list
  Name      Url                           Bearer Token Env Var  Status   Auth
  context7  https://mcp.context7.com/mcp  -                     enabled  Not logged in

  $ codex mcp get context7
  context7
    enabled: true
    transport: streamable_http
    url: https://mcp.context7.com/mcp
    bearer_token_env_var: -
    http_headers: CONTEXT7_API_KEY=*****
    env_http_headers: -

What steps can reproduce the bug?

  1. Configure an MCP server such as Context7 in Codex:

[mcp_servers.context7]
url = "https://mcp.context7.com/mcp"
enabled = true

[mcp_servers.context7.http_headers]
CONTEXT7_API_KEY = "redacted"

  1. Verify Codex sees it:

codex mcp list
codex mcp get context7

  1. Run Codex with a custom provider over Responses API:

codex -a never exec --ephemeral --skip-git-repo-check --sandbox read-only \
-m gpt-5.4 \\
-c 'model_provider="test"' \\
-c 'model_reasoning_effort="high"' \\
-c 'model_providers.test.name="test"' \\
-c 'model_providers.test.base_url="http://127.0.0.1:9000/v1"' \\
-c 'model_providers.test.env_key="OPENAI_API_KEY"' \\
'check if context7 is available in mcp tools in your session'

  1. Observe that inside the session, MCP discovery returns no resources/templates and Context7 is unavailable.
  2. Run the same kind of check with the native provider.
  3. Observe that Context7 is available there.

What is the expected behavior?

If an MCP server is configured and enabled, it should be available in-session regardless of whether Codex is using the native provider or a custom provider over the Responses API

Additional information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗