Codex Desktop MCP settings list does not show OAuth login/status per server

Open 💬 3 comments Opened May 19, 2026 by jirayu3141

Bug: Codex Desktop MCP settings list does not show OAuth login/status per server

Summary

Codex Desktop's Settings -> MCP servers screen lists configured MCP servers with a gear icon and enabled toggle, but it does not show which servers require OAuth login, which are already authenticated, or any per-server "Authenticate"/"Login" action.

This is confusing when one or more MCP servers need authentication. The CLI can expose auth metadata with codex mcp list --json, but the Desktop UI flattens all servers into the same enabled/disabled row state.

Environment

  • Codex CLI: codex-cli 0.130.0
  • Codex Desktop app version: 26.513.31313
  • Codex Desktop bundle version: 2867
  • Platform: macOS, Apple Silicon
  • Install path: /Applications/Codex.app

Relevant feature flags:

auth_elicitation                        under development  false
enable_mcp_apps                         under development  false
tool_call_mcp_elicitation               stable             true

Launching the app with codex app --enable auth_elicitation did not change the MCP settings list behavior.

Steps to reproduce

  1. Configure multiple MCP servers, including Streamable HTTP servers that support OAuth.
  2. Open Codex Desktop.
  3. Go to Settings -> MCP servers.
  4. Observe the server list.
  5. Compare the UI against:
codex mcp list --json

Actual behavior

The Desktop settings screen shows each MCP server row with only:

  • server name
  • gear icon
  • enabled/disabled toggle

It does not show:

  • OAuth status
  • whether the server needs login
  • whether the server is authenticated
  • an Authenticate / Login button
  • the CLI command to repair auth, such as codex mcp login <server-name>

Example redacted CLI state from the same machine:

[
  {
    "name": "oauth-server-a",
    "enabled": true,
    "transport_type": "streamable_http",
    "auth_status": "o_auth"
  },
  {
    "name": "oauth-server-b",
    "enabled": true,
    "transport_type": "streamable_http",
    "auth_status": "o_auth"
  },
  {
    "name": "stdio-server",
    "enabled": true,
    "transport_type": "stdio",
    "auth_status": "unsupported"
  }
]

The CLI has per-server auth metadata, but the Desktop settings UI does not render it.

Expected behavior

The MCP settings list should expose per-server auth health and actionability. For example:

  • Connected
  • Needs login
  • Auth expired
  • Unsupported auth
  • Authenticate / Login button for OAuth servers

If the Desktop UI cannot handle OAuth login directly, it should at least identify the affected MCP server and show the repair command:

codex mcp login <server-name>

Why this matters

When Codex reports that an MCP needs authentication, users need to know which server is affected. Right now, all rows look healthy/enabled, so the user has to inspect CLI JSON or manually test each MCP server.

This is especially confusing because the official docs say OAuth MCP servers can be authenticated with codex mcp login <server-name>, and the app settings docs say the app starts the auth flow when a server requires OAuth.

Related public reports

This appears related to existing MCP auth/status surfacing issues:

  • openai/codex#20009: OAuth MCP authenticates, but Desktop/runtime reports or surfaces auth/tool state incorrectly.
  • openai/codex#22072: auth_status: o_auth and saved OAuth credentials can affect MCP startup behavior in Codex 0.130.0.

Attachments

<img width="881" height="819" alt="Image" src="https://github.com/user-attachments/assets/9333848a-a4c4-4fd3-a0f7-dece11d8219a" />

I can attach a screenshot of Settings -> MCP servers showing rows with only server name, gear icon, and toggle, with no auth status or login button.

View original on GitHub ↗

3 Comments

jshaofa-ui · 3 months ago

Proposed Solution: MCP Settings OAuth Login Status Per Server

Root Cause

The Desktop settings UI fetches MCP server configuration but does not include or render the auth_status field that the CLI provides via codex mcp list --json. The data model has the information available, but the UI component only renders name, gear icon, and enabled toggle.

Proposed Fix

  1. Include auth_status in data model — Ensure Desktop fetches auth_status for each server
  2. Add auth status indicator — Render badges: "🔒 Needs Login" for OAuth servers, "✓ Connected" for others
  3. Add Authenticate button — Trigger OAuth flow via codexMCP.login(serverName)
  4. Fallback: CLI repair command — Show codex mcp login <server-name> when in-UI auth unavailable
{server.auth_status === 'o_auth' && (
  <span className="auth-badge">
    🔒 Needs Login
    <button onClick={() => authenticateServer(server.name)}>Authenticate</button>
  </span>
)}
{server.auth_status === 'unsupported' && (
  <span className="auth-badge">✓ Connected</span>
)}

Testing Strategy

  • Unit: auth_status rendering for each status value
  • Integration: authenticateServer() triggers OAuth flow, refreshes list
  • E2E: Configure OAuth server → open settings → see "Needs Login" → Authenticate → status updates

Impact

Medium effort (~150 lines, 3 files). Eliminates confusion about which MCP servers need authentication.

Full solution: solutions/codex-23453-mcp-settings-oauth-login-status-fix.md

bendavis78 · 2 months ago

This would be very helpful. There is currently no way (that I can tell) to authenticate w/ an OAuth MCP server in Codex Desktop w/o using the CLI, and the chat session skips over plugins/mcp server as if it doesn't exist. This can make it very confusing to users who just installed a plugin that requires OAuth.

devrenzz · 1 month ago

Adding some detail on when the Authenticate button does and doesn't appear, since it looks random but isn't. A freshly added OAuth MCP server shows no button until you fully quit and reopen the app — auth state is only checked at launch, never when a server is added. Worse, if the app has an old credential stored for that server (keychain, "Codex MCP Credentials"), the button never appears at all — the app treats "credential exists" as logged in even when the tokens have been revoked server-side, and the server just silently fails with no way to re-authenticate from the UI. Our whole team hit this after a token rotation, and the only fix was manually deleting the keychain entry and restarting the app, which no normal user is going to figure out. Per-server auth status plus a re-login option would solve all of it.