Failed to Resume Chat: Allow Codex sessions to start when an optional MCP fails initialization

What version of the IDE extension are you using?

26.901.22334

What subscription do you have?

API

Which IDE are you using?

VS Code

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

When an MCP server configured in config.toml is unavailable because its endpoint requires authentication, the Codex VS Code extension fails to start/resume the Codex session entirely.

The error shown is:

Failed to resume chat
error resuming thread: Fatal error: Failed to initialize se...
[codex_mcp_client::event_notification_transport::Event...
error: Auth required, when send initialize request

The error does not identify which configured MCP server failed. It also only displays very briefly so it is hard to read in full. It does however, repeatedly popup as the extension attempts to reconnect periodically.

In my case, the MCP endpoint is intentionally protected by an HTTP authentication layer. The MCP configuration itself is valid and the MCP works normally when that authentication layer is disabled.

This means that an authentication requirement on an otherwise optional MCP prevents Codex from starting a coding session at all.

What steps can reproduce the bug?

1. Configure an HTTP MCP server in config.toml.
2. Ensure the MCP server is working normally.
3. Put an HTTP authentication layer in front of the MCP endpoint (such as frontend password protection used for staging sites) that returns 401 unless authenticated.
4. Start or resume a Codex session in the VS Code extension.
5. Codex attempts to initialize the configured MCP.
6. The MCP initialization fails with:
   Auth required, when send initialize request
7. The Codex session fails to start/resume.

As an A/B test, disabling the HTTP authentication layer allows the same Codex configuration and MCP server to initialize successfully and the Codex session starts normally.

What is the expected behavior?

A failure to initialize an MCP should not prevent the Codex session from starting unless that MCP has explicitly been configured as required.

Ideally, Codex would support either:

• a per-MCP setting indicating that the server is optional, or
• a global setting to allow Codex sessions to start while unavailable MCPs are skipped.

For example, an unavailable MCP could produce a warning such as:

MCP "<specific MCP interface>" could not be initialized: authentication required.
Continuing without this MCP.

rather than preventing the entire Codex session from starting.

It would also be valuable for the error to identify the specific MCP server/gateway that failed. As MCP adoption grows, users may have multiple MCP servers configured, and a generic authentication error makes it difficult to determine which integration is causing the session initialization failure.

This would make Codex more resilient to temporary MCP outages, expired credentials, network failures, or intentionally protected endpoints, while also making failures substantially more actionable.

Additional information

Additional information

This appears particularly relevant because MCP initialization currently seems to occur as part of Codex session initialization rather than only when an MCP is actually needed.

In my case, I deliberately protect the frontend/MCP endpoint with authentication. I can work around the problem by temporarily disabling the authentication layer before starting Codex and re-enabling it afterwards, but this is inconvenient and creates an unnecessary risk of accidentally leaving the endpoint exposed.

I also previously found that, after running through the above disable/re-enable process, providing the frontend password to Codex allowed the MCP interaction to work. However, this does not appear to provide a reliable solution for the initial MCP initialize request.

The most useful improvement would therefore be to make MCP initialization failure non-blocking for MCPs that are not explicitly required, while also reporting the specific MCP responsible for any initialization failure.
This would save time during development and make MCP configuration considerably easier to diagnose as the number of MCP configurations grows.

The error should also display until closed by the user. In my case it would display intermittently for a couple seconds at a time and self-close.

Start by reproducing the failure with an HTTP MCP configured in config.toml and a 401 authentication response through the VS Code extension. Trace MCP initialization during session start or resume and determine how optional versus required servers should be represented. Done means the Codex session starts without an unavailable optional MCP, while the warning identifies the specific server and authentication failure.