MCP startup suggests codex mcp login for bearer-token auth failures

Open 💬 2 comments Opened Jun 6, 2026 by sanjumsanthosh

What version of Codex CLI is running?

0.137.0

What subscription do you have?

Enterprise

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

iTerm2

Codex doctor report

What issue are you seeing?

Codex currently shows misleading remediation for some MCP startup auth failures.

For remote MCP servers configured with bearer_token_env_var, a startup failure that contains Auth required is currently surfaced as:

Codex currently shows misleading remediation for some MCP startup auth failures.

That message reads like an OAuth-login problem, but for bearer-token-configured servers the real issue is more likely that the configured token is missing, expired, invalid, or rejected by the server.

https://github.com/openai/codex/blob/87b808bb570f01f4b6fc8485c5459052fac0e320/codex-rs/codex-mcp/src/connection_manager.rs#L811-L852

So any startup error containing Auth required gets mapped to the codex mcp login hint, even when the server is configured to use bearer-token auth.

What steps can reproduce the bug?

  1. Configure a remote MCP server with bearer_token_env_var in ~/.codex/config.toml.
  2. Set that environment variable to a bearer token value.
  3. Make the token invalid for the server, for example by using an expired or rejected token.
  4. Start Codex or trigger MCP server startup.
  5. Observe that Codex reports the server as “not logged in” and suggests codex mcp login <server> instead of pointing to the configured bearer token as the likely source of the failure.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

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