DingTalk Streamable HTTP MCP servers are incorrectly gated behind OAuth/login

What issue are you seeing?

Codex appears to incorrectly require OAuth/login for DingTalk Streamable HTTP MCP servers, even though these servers work without OAuth in other MCP clients and respond successfully to direct MCP JSON-RPC requests.

Affected MCP marketplace entry:

• DingTalk MCP Marketplace: https://aihub.dingtalk.com/#/detail?instanceId=116031&detailType=instanceMcpDetail&mcpId=2034

Affected MCP server names in my Codex config:

• 钉钉待办
• DingTalk A1
• 机器人消息
• 钉钉 AI 表格
• 钉钉文档
• 钉钉日历
• 钉钉群聊
• 钉钉表格

For the main repro, I used 钉钉待办.

What version of Codex is running?

codex-cli 0.128.0-alpha.1

Which model were you using?

This is MCP tool-discovery/auth behavior before the model can call the MCP tools.

What platform is your computer?

macOS / Darwin. Reproduced in Codex Desktop with the local Codex CLI.

What steps can reproduce the bug?

1. Add a DingTalk MCP server from the DingTalk MCP marketplace using Streamable HTTP transport. Example config shape:

[mcp_servers."钉钉待办"]
type = "streamable-http"
url = "https://mcp-gw.dingtalk.com/server/<redacted>?key=<redacted>"

1. Run:

codex mcp list --json

1. Observe that Codex reports the DingTalk Streamable HTTP MCP servers as auth_status: "not_logged_in".

Example sanitized output:

{
  "name": "钉钉待办",
  "enabled": true,
  "transport": {
    "type": "streamable_http",
    "url": "https://mcp-gw.dingtalk.com/server/<redacted>?key=<redacted>",
    "bearer_token_env_var": null,
    "http_headers": null,
    "env_http_headers": null
  },
  "auth_status": "not_logged_in"
}

1. In Codex Desktop, the server shows an authentication prompt and the MCP tools are not exposed to the agent.

1. Direct MCP JSON-RPC requests to the same server succeed without OAuth.

initialize returns HTTP 200 with MCP capabilities:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "experimental": {},
      "tools": {
        "listChanged": false
      }
    },
    "serverInfo": {
      "name": "dingtalk-mcp-<redacted>",
      "version": "1.0.0"
    }
  }
}

tools/list also succeeds and returns tools including:

• create_personal_todo
• get_user_todos_in_current_org
• update_todo_task
• delete_todo
• query_todo_detail
• add_todo_comment

tools/call for get_user_todos_in_current_org also succeeds:

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "{\"result\": {\"todoCards\": []}}"
      }
    ],
    "structuredContent": {
      "result": {
        "todoCards": []
      }
    },
    "isError": false
  }
}

What is the expected behavior?

Codex should connect to Streamable HTTP MCP servers that do not require OAuth and expose their tools to the agent.

If a Streamable HTTP MCP server is reachable and initialize / tools/list succeeds without OAuth, Codex should not mark the server as not_logged_in or block tool exposure behind an OAuth login flow.

What do you see instead?

Codex marks these DingTalk MCP servers as not_logged_in, prompts for authentication, and does not expose the tools to the agent.

This makes the MCP unusable in Codex, even though the same MCP configuration works in Qoderwork and Claude without OAuth, and direct MCP JSON-RPC requests to the endpoint succeed.

Additional information

The issue seems to be in Codex's HTTP MCP auth discovery/status handling. It looks like Codex may be treating Streamable HTTP MCP auth as a hard OAuth requirement for this server, even though the server does not require OAuth for normal MCP initialization, tool listing, or at least some tool calls.

This is not just a generic DingTalk configuration problem: Codex correctly parses the server as transport: streamable_http, but the auth_status: not_logged_in state prevents the tools from being surfaced in the Codex agent environment.