MCP bearer-token env var appears configured even when missing from active process

What version of Codex CLI is running?

codex-cli 0.142.0

What platform is your computer?

macOS arm64 / Codex Desktop-bundled CLI

What issue are you seeing?

For a Streamable HTTP MCP server configured with bearer_token_env_var, codex mcp list and codex mcp get can make the server look bearer-authenticated even when the referenced environment variable is not visible to the active Codex process. The actual MCP request then reaches the server without an Authorization header, so protected tools are hidden or startup fails.

This is confusing because the status path says the server has bearer auth configured, while the runtime path cannot send it. codex doctor does notice an MCP warning, but the more direct MCP commands do not surface the missing env var or tell the user that the active Desktop/thread/process needs a restart after the launcher environment is changed.

No token values are included in this report.

What steps can reproduce the bug?

1. Configure a remote Streamable HTTP MCP server with a bearer-token env var:

``toml
[mcp_servers.example]
url = "https://example.com/mcp"
bearer_token_env_var = "EXAMPLE_MCP_TOKEN"
``

1. Launch Codex Desktop or Codex CLI from an environment where EXAMPLE_MCP_TOKEN is not present.
2. Run codex mcp list or codex mcp get example.
3. Attempt to use the MCP server from the active Codex session.

Observed behavior

In a real repro with a Breakdown MCP server:

$ codex mcp get breakdown
breakdown
  enabled: true
  transport: streamable_http
  url: https://www.breakdown.sh/api/mcp
  bearer_token_env_var: BREAKDOWN_API_TOKEN
  http_headers: -
  env_http_headers: -

$ printenv BREAKDOWN_API_TOKEN >/dev/null && echo set || echo missing
missing

$ codex mcp list
Name       Url                               Bearer Token Env Var  Status   Auth
breakdown  https://www.breakdown.sh/api/mcp  BREAKDOWN_API_TOKEN   enabled  Bearer token

The server-side MCP diagnostic reports that the request arrived without a bearer token:

{
  "ok": false,
  "state": "missing_token",
  "summary": "Breakdown MCP is reachable, but this request did not include a bearer token.",
  "error": { "code": "unauthorized", "message": "Missing bearer token" }
}

codex doctor --summary does catch a generic warning:

[!!] mcp  MCP configuration has optional issues - Set the missing MCP env vars or disable the affected server.

But the direct codex mcp list/get flow still reads as if bearer auth is ready, and the active MCP tool surface remains unusable until the process/thread is restarted with the env var available.

Expected behavior

Codex should distinguish these states in the MCP status path:

• bearer-token env var is configured
• bearer-token env var is present in the current process environment
• bearer-token env var is missing, so no Authorization header will be sent

Concretely, one or more of these would help:

• codex mcp list/get should show a warning/status such as missing env var EXAMPLE_MCP_TOKEN instead of only Auth: Bearer token.
• codex doctor should make the missing server/env-var actionable from the default output, while still redacting secret values.
• The active Desktop/thread MCP startup error should say that the configured bearer-token env var is missing from the process environment and that restarting Codex is required after changing GUI/launcher env vars.
• If Codex supports live MCP client/session refresh, changing MCP auth config or logging in should invalidate/recreate the active MCP client; otherwise the UI should explicitly say a new process/thread is required.

Additional information

This may overlap with other MCP auth/session-state reports, but this issue is specifically about bearer_token_env_var being configured while absent from the active process environment. Related issues I found while checking for duplicates:

• #29279: active Desktop thread remains stuck after MCP OAuth login/state changes
• #26760: bearer-token auth failures can suggest the wrong OAuth remediation
• #26072: Streamable HTTP MCP server appears enabled/authenticated but tools are not exposed