MCP OAuth login does not persist across Codex restarts; remote MCP startup incomplete

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #13852
• #14144
• #14991
• #13956

Powered by Codex Action

I have the same issue as well codex MCP tokens do not persist after restarts

Additional findings from local debugging on the same machine (0.115.0, macOS arm64):

asana is configured correctly and new Codex sessions are initializing all configured MCP servers successfully. In my local logs, fresh sessions after the OAuth flow show session_init.enabled_mcp_server_count=4, so this no longer looks like an Asana startup/handshake failure during session init.

The failure happens later, when Codex actually tries to use the Asana MCP. A fresh codex exec run reproduced the low-level transport/auth error from the Asana server:

AuthRequired(AuthRequiredError {
  www_authenticate_header: "Bearer realm=\"Asana MCP\", resource_metadata=\"https://mcp.asana.com/.well-known/oauth-protected-resource/v2\", error=\"invalid_token\", error_description=\"Invalid token signature - token was not issued by Asana OAuth\""
})

That same run then reported no Asana tools available.

A few related signals:

• codex mcp login asana can complete successfully.
• codex mcp list --json still reports asana with "auth_status": "unsupported".
• codex mcp get asana --json shows only the raw MCP URL and no bearer token env var / tool restriction config.
• In the affected sessions, there are no failed to start / initialize errors for Asana in the main Codex log, even though the model still cannot use any Asana tools.

This makes the bug look more specific than “OAuth login does not persist”: Codex appears to be reaching https://mcp.asana.com/v2/mcp, but when it authenticates requests it is sending a token that Asana rejects as not being Asana-issued OAuth. In other words, the MCP server is configured and counted during init, but Asana tools never become callable because the runtime auth handoff is wrong.

If useful, I can add exact local commands / outputs as a tighter repro.

I’ve experienced the same thing with the MCP I use for WordPress.

In my case, the MCP had clearly lost authentication, but there didn’t seem to be any way to reauthenticate the existing connection in place. There was no obvious reconnect or sign-in-again option, so it stayed configured but was no longer usable.

The only way I was able to get it working again was to remove the MCP completely and set it up again from scratch. That forced the auth flow to run properly and restored access.

So the problem, at least from what I saw, wasn’t that reauthentication failed. It was that once the existing connection had fallen out of a valid auth state, there didn’t seem to be any proper reauthentication path at all.

Still reproduces on codex-cli 0.125.0 with the same Asana config (https://mcp.asana.com/v2/mcp).

Current findings:

• codex mcp list --json shows asana enabled, but auth_status: "unsupported".
• Session init counts the configured MCP servers, so this is not a TOML/endpoint startup issue.
• A fresh codex exec probe fails when the Asana MCP transport authenticates:

AuthRequired ... error="invalid_token",
error_description="Invalid token signature - token was not issued by Asana OAuth"

The probe then returns NO_ASANA_TOOLS.

Diagnosis: Codex reaches Asana MCP, but does not present an Asana-issued OAuth token, so Asana rejects the request and no Asana tools are exposed.

Note: works in Claude-code.

Asana’s official MCP Server URL https://mcp.asana.com/v2/mcp has a login persistence issue with Codex — login works, but Codex shows you as logged out after restart.

Switching the MCP URL to https://mcp.asana.com/mcp fixes it.

Also related: https://github.com/openai/codex/issues/17265

It may help to split the visible auth state into more than “logged in / unsupported / invalid token.” Remote MCP auth failures can come from different layers that require different fixes.

A more actionable state taxonomy might be:

configured_no_auth_required
configured_auth_required_not_started
oauth_flow_started
oauth_callback_succeeded
token_persisted
token_loaded_by_runtime
token_rejected_by_server
tools_list_succeeded
tools_list_failed_after_auth

The current user experience collapses several of these into “invalid token,” which makes it hard to tell whether the token was never written, written to the wrong store, not reloaded after restart, or rejected by the MCP server.

For privacy, the diagnostic does not need token contents. It only needs store type/path bucket, connector name, timestamp, and the last successful transition. That would make remote MCP auth bugs much easier to compare across Asana, Notion, Linear, and custom servers.

Same issue here. The same MCP server auth persists across Claude Code sessions but do not persist across Codex sessions, suggesting it is a Codex issue instead of the server issue.

experiencing the same issue in v0.144.5 as described when wanting to use the Youtrack MCP Server via oAuth. You can try it yourself with a free youtrack cloud instance