MCP OAuth succeeds but Espressif Documentation server returns HTTP 403 during initialize

What version of Codex CLI is running?

codex-cli 0.150.0-alpha.12.2 (Codex Desktop 26.825.3734.0)

What subscription do you have?

API key

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Microsoft Windows 10.0.26200 x64 (Windows 11 ProfessionalWorkstation)

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

Codex Desktop with PowerShell 7.6.5. This reproduces in a fresh CLI process on native Windows, not WSL.

Codex doctor report

Relevant results from codex doctor:

• MCP configuration is locally consistent.
• The server is configured as streamable HTTP.
• Network environment is readable; no proxy environment variables are set.
• Provider HTTP reachability succeeds.
• Codex Desktop app-server handshake succeeds.

The full report contains unrelated local paths and private-network endpoint information, so it is not included here.

What issue are you seeing?

OAuth for the Espressif Documentation remote MCP server completes successfully in the browser, and codex mcp login reports success. However, a fresh Codex process fails when sending the MCP initialize request:

MCP client for `espressif-documentation` failed to start:
HTTP 403: {"error":{"code":"403","message":"Forbidden","id":"hnd1::q4pmn-1787899236531-b4965e4cbded"}}

Configuration:

[mcp_servers.espressif-documentation]
url = "https://mcp.espressif.com/docs"

codex mcp get reports the server as enabled with streamable_http transport and no custom headers.

Two other Espressif MCP endpoints work in equivalent smoke tests:

• ESP Component Registry: https://components.espressif.com/mcp
• Espressif Engineering: https://ts-mcp.espressif.com/mcp

Only the OAuth-protected documentation endpoint fails.

What steps can reproduce the bug?

1. Configure the server shown above.
2. Run codex mcp logout espressif-documentation to clear any stale OAuth state.
3. Run codex mcp login espressif-documentation.
4. Complete GitHub authentication in the browser. The browser and CLI both report successful authentication.
5. Start a fresh codex exec process that loads the MCP server.
6. Observe that the initialize request receives HTTP 403 before any documentation tools are exposed.
7. Repeat logout/login and start another fresh process; the result is unchanged.

What is the expected behavior?

After a successful OAuth login, Codex should initialize the MCP server and expose its documentation tools.

If the server is returning 403 because the token lacks a required scope, Codex should inspect the WWW-Authenticate response and perform OAuth step-up authentication, or at minimum report the required scope.

Additional information

Espressif's official discussion for this server is:

• https://github.com/espressif/developer-portal/discussions/696

That discussion contains a WSL callback-routing report, but this reproduction is different: the OAuth callback succeeds on native Windows and the failure occurs afterward during MCP initialization.

Related Codex issues, but neither is an exact duplicate:

• #20518 tracks missing OAuth step-up handling for 403 insufficient_scope. This may be related if the Espressif response contains that WWW-Authenticate error, but the visible JSON body here only says Forbidden.
• #20513 tracks error reporting for non-2xx MCP responses. The current version already surfaces the actual HTTP 403, so the remaining failure is authentication/authorization rather than deserialization.
• #33151 concerns an OpenAI connector callback returning 403 after browser OAuth, not a remote MCP server rejecting initialize.

An authenticated GitHub search found no existing issue or comment containing both the exact endpoint and Forbidden/HTTP 403.