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

Open 💬 5 comments Opened May 7, 2026 by wadjj

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

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>"

Run:

codex mcp list --json

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"
}

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

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

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

#20009

Powered by Codex Action

Mahkhmood9 · 3 months ago

refrencing https://github.com/openai/codex/pull/17098

as per @wadjj are you sure you are unable to maybe download the mcp extention

are you sure its not an issue with dingtalk-mcp?

wadjj · 3 months ago

refrencing https://github.com/openai/codex/pull/17098 as per @wadjj are you sure you are unable to maybe download the mcp extention are you sure its not an issue with dingtalk-mcp?

Yes i am sure, I'm using the same set of mcps across multiple agents(claude,qoderwork,craft agents). The problem only manifests with Codex

NoobDPer · 3 months ago

Additional finding: Chinese server names are not accepted by Codex

Confirming this bug. Additionally, I found another related issue that prevents DingTalk MCP from working at all:

Problem: Codex rejects non-ASCII characters in `[mcp_servers]` keys

When you try to configure a DingTalk MCP server using its Chinese display name (as shown in the DingTalk marketplace), like:

[mcp_servers."钉钉文档"]
type = "streamable-http"
url = "https://mcp-gw.dingtalk.com/server/..."

Codex silently fails to load the server — no error is shown, but the server does not appear in codex mcp list. This means even without the auth bug, DingTalk MCP servers with Chinese names are effectively broken in Codex.

Root cause
The TOML key "钉钉文档" contains non-ASCII (CJK) characters. Codex's config parser (or the underlying MCP server registration logic) appears to only support ASCII identifiers in server names.

Workarounds
Use ASCII keys in config.toml — Rename the server to an ASCII alias:

[mcp_servers."dingtalk-docs"]
type = "streamable-http"
url = "https://mcp-gw.dingtalk.com/server/..."

This bypasses the Chinese name parsing issue, but you will still hit the auth_status: not_logged_in bug described in this issue.

> refrencing #17098 > as per @wadjj are you sure you are unable to maybe download the mcp extention > are you sure its not an issue with dingtalk-mcp? Yes i am sure, I'm using the same set of mcps across multiple agents(claude,qoderwork,craft agents). The problem only manifests with Codex

Mahkhmood9 · 3 months ago

## Additional finding: Chinese server names are not accepted by Codex Confirming this bug. Additionally, I found another related issue that prevents DingTalk MCP from working at all: ### Problem: Codex rejects non-ASCII characters in [mcp_servers] keys When you try to configure a DingTalk MCP server using its Chinese display name (as shown in the DingTalk marketplace), like: [mcp_servers."钉钉文档"] type = "streamable-http" url = "https://mcp-gw.dingtalk.com/server/..." Codex silently fails to load the server — no error is shown, but the server does not appear in codex mcp list. This means even without the auth bug, DingTalk MCP servers with Chinese names are effectively broken in Codex. Root cause The TOML key "钉钉文档" contains non-ASCII (CJK) characters. Codex's config parser (or the underlying MCP server registration logic) appears to only support ASCII identifiers in server names. Workarounds Use ASCII keys in config.toml — Rename the server to an ASCII alias: [mcp_servers."dingtalk-docs"] type = "streamable-http" url = "https://mcp-gw.dingtalk.com/server/..." This bypasses the Chinese name parsing issue, but you will still hit the auth_status: not_logged_in bug described in this issue. > > refrencing #17098 > > as per @wadjj are you sure you are unable to maybe download the mcp extention > > are you sure its not an issue with dingtalk-mcp? > > > Yes i am sure, I'm using the same set of mcps across multiple agents(claude,qoderwork,craft agents). The problem only manifests with Codex

see https://github.com/openai/codex/commits/main/codex-rs/codex-mcp/src/mcp/auth.rs

the auth.rs had a lot of commits recently, maybe its an interduced bug , you think you can check older version and confirm the issue is real?
you suggest its not autherizing, and fail to login/oauth?
Taiwanese/Chinese/Korean web services are natourious for being hard for non westerns e g requiring a chinese phone number +81
perhaps you need to autherize -- good thing mcp is an open format so it should be easy

see
https://github.com/fishwww-ww/dingtalk-mcp/blob/main/gemini-extension.json

maybe you can port it for codex

maybe you can see refrence if something has changedo ndingtalk behalf
https://mcp.dingtalk.com/
maybe
https://github.com/open-dingtalk/dingtalk-mcp
or
https://open.dingtalk.com/