Context7 local MCP with API key appears routed through stale OAuth app connector

Summary

A configured local Context7 MCP server with http_headers.CONTEXT7_API_KEY is loaded by Codex and works through direct MCP HTTP calls, but the exposed mcp__context7 tool in the running Codex session returns an OAuth error:

Invalid or expired OAuth token. Please re-authenticate to obtain a new token.

This looks like the exposed Context7 tool namespace is being routed through a stale OAuth/app connector path, or colliding with one, instead of the configured local MCP server.

Environment

• Product: Codex Desktop App on macOS
• App version observed in local state: 26.616.71553
• Platform: macOS
• MCP transport: Streamable HTTP
• MCP server: https://mcp.context7.com/mcp
• Local config file: ~/.codex/config.toml

Local MCP config

The local config contains:

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

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

I also tried adding a second local alias to avoid a name collision:

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

[mcp_servers.ctx7.http_headers]
CONTEXT7_API_KEY = "<redacted>"

The alias parsed correctly, but it did not appear in the live tool surface during the current session.

Observed behavior

Codex exposes these tools:

mcp__context7.resolve_library_id
mcp__context7.query_docs

Calling mcp__context7.resolve_library_id returns:

Invalid or expired OAuth token. Please re-authenticate to obtain a new token.

This persists after replacing the Context7 API key multiple times.

Verification that local MCP config works

The local config is valid:

• TOML parses successfully.
• context7 has the expected URL.
• context7.http_headers.CONTEXT7_API_KEY is present.
• File permissions remain 600.

Codex runtime logs show RefreshMcpServers loaded context7 with http_headers.CONTEXT7_API_KEY:

"context7": Object {
  "url": String("https://mcp.context7.com/mcp"),
  "http_headers": Object {"CONTEXT7_API_KEY": String("<redacted>")},
  "environment_id": String("local"),
  "enabled": Bool(true)
}

A direct MCP HTTP session against the same endpoint works. The direct test performed:

1. initialize
2. Extracted the returned Mcp-Session-Id
3. Sent notifications/initialized
4. Called tools/call with resolve-library-id

The direct call successfully resolved AKS docs and returned results including:

Context7-compatible library ID: /microsoftdocs/azure-aks-docs
Title: Azure Kubernetes Service
Source Reputation: High

So the Context7 endpoint is reachable and the local configuration is not the failing part.

Possible contributing factor

There is also a cached ChatGPT app-directory entry for Context7:

id: asdk_app_69ef18c674308191a2f952431f91ea61
name: Context7
description: Fetch Up-to-date Docs

The error string returned by the exposed tool is OAuth-specific, while the local MCP config uses an API-key header. That suggests the exposed mcp__context7 namespace may be bound to, or colliding with, the app connector OAuth route rather than the local MCP server route.

Expected behavior

If [mcp_servers.context7] is configured and loaded with http_headers, the exposed mcp__context7 tools should call that configured local MCP server successfully.

If there is both a local MCP server and a ChatGPT app connector named Context7, Codex should avoid ambiguous routing or expose distinct namespaces.

Actual behavior

The local MCP route works through direct HTTP, but the exposed mcp__context7 tool returns an expired OAuth token error.

Related issues

This seems related to, but not exactly the same as:

• #27165
• #14144
• #14242
• #19363

Those cover stale OAuth token handling and Context7 or MCP discovery issues. This report is specifically about a configured API-key-backed local Context7 MCP route appearing to fail through an OAuth-backed tool binding.