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

[petabook]

What version of Codex CLI is running?

0.115.0

What subscription do you have?

Business

Which model were you using?

gpt-5.4

What platform is your computer?

Darwin 25.2.0 arm64 arm

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

ghostty

What issue are you seeing?

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

Summary

After successfully authenticating an OAuth-based MCP server with codex mcp login asana, starting a new Codex session reports:

The asana MCP server is not logged in. Run codex mcp login asana.

At the same time, other configured MCP servers fail during startup/handshake.

Environment

• Codex CLI version: 0.115.0
• Install path: /opt/homebrew/bin/codex
• OS: macOS
• HOME: /Users/snd
• CODEX_HOME: unset
• Config path: ~/.codex/config.toml
• Auth cache path: ~/.codex/auth.json

Config

model = "gpt-5.4"

[mcp_servers.asana]
url = "https://mcp.asana.com/v2/mcp"

[mcp_servers.sentry]
url = "https://mcp.sentry.dev/mcp"

[mcp_servers.newrelic]
url = "https://mcp.newrelic.com/mcp/"

### What steps can reproduce the bug?

Configure remote MCP servers in `~/.codex/config.toml`
Run `codex mcp login asana`
Complete OAuth successfully
Start Codex with `codex`

### What is the expected behavior?

Codex should reuse the stored OAuth session and start with the Asana MCP server authenticated.

### Additional information

⚠ MCP client for `newrelic` failed to start: MCP startup failed: handshaking with MCP server failed: Send message error Transport ... error decoding response body, when send initialize request

⚠ MCP startup incomplete (failed: asana, newrelic)

[github-actions]

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

• Supabase MCP repeatedly requires reauthentication: OAuth token refresh failed during initialize #13852
• MCP OAuth reauth succeeds but active session still uses stale refresh token (invalid_grant) #14144
• rmcp MCP OAuth sessions do not recover on 401 invalid_token; stale session fails while new session succeeds #14991
• Notion MCP stuck after refresh token invalid_grant; Codex Desktop doesn't prompt re-auth #13956

Powered by Codex Action

[WeTheKey]

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

[petabook]

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.

[MentalityUnhinged]

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.