Feature Request: Support dynamic reloading of MCP HTTP headers on auth failure (401/403)

Open 💬 6 comments Opened Nov 26, 2025 by jdsalasca

💡 Likely answer: A maintainer (jdsalasca, contributor) responded on this thread — see the highlighted reply below.

What feature would you like to see?

Context

I am using an MCP server that requires a custom authentication header (e.g., a Bearer token) defined in the config.toml. Currently, my configuration looks like this:

[mcp_servers.enterprise_mcp]
transport = "http"
url = "https://enterprise_[mcp-mcp.enterprisedomain.com/mcp](https://mcp-mcp.enterprisedomain.com/mcp)"
startup_timeout_sec = 30
[mcp_servers.enterprise_mcp.http_headers]
x-token = "Bearer {{token}}"

The Problem

The authentication tokens for my enterprise environment expire every 3 hours. When a token expires, the MCP connection fails. Although I can update the token in config.toml, the current session (Codex) does not detect this change or reload the connection parameters.

Current Workaround & Impact
To restore connectivity, I am forced to kill and restart the entire Codex session.

This causes a complete loss of chat context and history.

I have to start my workflow from scratch every 3 hours.

This creates significant friction and limits the usability of MCP for long-running tasks.

Proposed Solution
I would like to request a feature that handles authentication failures gracefully without killing the session. Specifically:

Detect Failure: If the MCP server responds with a 401 Unauthorized or 403 Forbidden.

Check Config: The system should check if config.toml has been modified since the last load.

Hot Reload: If the config has changed (e.g., a new token was pasted), automatically reload the MCP connection/headers.

User Prompt: If the config hasn't changed, prompt the user to update their credentials.

This would vastly improve the developer experience for users working with secure, short-lived token environments.

Thanks!

Additional information

_No response_

View original on GitHub ↗

6 Comments

jdsalasca contributor · 9 months ago

This has to be considered a bug too

jbranc · 7 months ago

/exit
codex resume

jdsalasca contributor · 7 months ago

yeah like we can do that: kill a conversation and resume it, agree but still so much steps for something that even sometimes could be entirely done by the mcp, It has to be done automatically without the neccesity to kill and restart the conversation

jbranc · 7 months ago

yes for sure - i agree this is a Bug not a feature request. the atlassian-rovo mcp will actually expire during a long execution run of the model, and therefore not be able to complete its task at the end until you reauth. its not ok.

razashariff · 5 months ago

Token expiry forcing full session restarts highlights the fragility of session-based authentication for MCP. MCPS (MCP Secure) takes a different approach — per-message signing with ECDSA P-256 agent passports. Each message is independently verifiable (nonce + timestamp + message_hash + signature), so there is no session token to expire or refresh.

The agent holds a cryptographic passport (valid for up to 365 days, revocable in real-time via Trust Authority) and signs every JSON-RPC message individually. No OAuth callbacks, no token refresh, no session state to manage.

Published as an IETF Internet-Draft and available on npm as mcp-secure (zero dependencies).

lukeyeager · 1 month ago

Or, even better, provide support for something like claude code's headersHelper config option.