Connect Codex to Slack

Slack ships its own MCP server at mcp.slack.com/mcp, and it’s a real one: search, read, send, react, and Canvas tools against a live workspace. Point Codex’s standard remote-server login at it and the login step fails before a browser even opens. This page explains why, and is honest about the one workaround we found and couldn’t confirm.

What you get

Connected, an agent gets real reach into a Slack workspace. It can search messages and channels, pull files, look up users, and read conversation history. It can also send messages, react with emoji, create channels, and read or write Canvases. Slack’s docs break each of those into its own OAuth scope, which matters later when the Gotchas section talks about locking specific scopes down.

Slack’s docs name four clients that connect with no code: Claude.ai, Claude Code, Perplexity, and Cursor. Codex isn’t on that list, and that gap is the entire subject of this page.

Setup

A Slack entry in config.toml looks like any other remote server: [mcp_servers.slack] with url = "https://mcp.slack.com/mcp". For the general shape, the auth key, and bearer_token_env_var, see Connect an MCP server rather than have it repeated here.

Slack’s own docs describe the transport as JSON-RPC 2.0 over Streamable HTTP and say plainly: “We do not support SSE-based connections or Dynamic Client Registration at this time.” Run the login step against that entry and you hit that line immediately. From openai/codex#13200, filed 2026-03-02 against codex-cli 0.105.0-alpha.8:

$ codex mcp login slack
Error: Registration failed: Dynamic registration failed: Registration failed: Dynamic client registration not supported

Codex’s remote OAuth login registers a client with the server at connect time. That registration step is Dynamic Client Registration, and Slack’s docs say the server won’t do it. Slack does publish RFC 8414 authorization server metadata at mcp.slack.com/.well-known/oauth-authorization-server, so discovery works fine; what Codex can’t do is get a client ID. Slack’s docs tell you to bring your own: “You’ll need to use your app’s client_id and client_secret for Slack OAuth.” That means a Slack app registered ahead of time at api.slack.com, not something Codex can request on the fly. The four supported clients are partner-built, and Slack doesn’t publish a client ID for anyone else to reuse.

We looked for a way past it before writing this page. One personal blog, blog.ianhsiao.me, describes registering your own Slack app, running the OAuth authorization-code exchange by hand with a browser and curl, and dropping the resulting xoxp- user token into bearer_token_env_var, the same mechanism any bearer-token remote server uses. We did not reproduce that exchange ourselves, so we’re not publishing it as a setup step. Two details made us cautious: it’s a single unreviewed source from 2026-04-30, and the token endpoint it curls (slack.com/api/oauth.v2.access) doesn’t match the endpoint Slack’s own MCP docs cite for this flow (slack.com/api/oauth.v2.user.access, paired with an oauth/v2_user/authorize authorization URL). That could be ordinary overlap between two Slack API generations, or it could mean the recipe pulls a token this server won’t accept. Until someone confirms which endpoint pair returns a token the MCP server takes, test it yourself before you wire it into any config.

If you do test it and land a real bearer token, wire it in the standard way: url plus bearer_token_env_var pointing at an environment variable, never a token typed directly into the config file. mcp_servers.<id>.env covers where that value belongs.

Gotchas

The DCR failure isn’t intermittent. Codex’s login flow needs the server to accept dynamic client registration, and Slack’s docs say it doesn’t. Retrying codex mcp login slack won’t produce a different result. As of 2026-07-16, #13200 is still open with no maintainer response, four months after it was filed.

Slack’s supported-client list doesn’t include Codex. Claude.ai, Claude Code, Perplexity, and Cursor are the four partner-built clients Slack names. There’s no client ID sitting in the docs for Codex to reuse. Slack’s wording is “at this time,” so this may change; as of 2026-07-16 it hasn’t.

A working bearer token still needs clamping. The scopes behind this server include chat:write, reactions:write, canvases:write, and channels:write. An agent holding a working token can post messages and edit Canvases in a live workspace, not only read them. If you get a token working, put those tools in disabled_tools or set default_tools_approval_mode = "writes" before pointing an agent at a real workspace. Both are documented on Connect an MCP server.

One bad entry can take every server down with it. openai/codex#6020 reports a single malformed mcp_servers block failing every configured server’s handshake at once. If you’re hand-editing a Slack entry next to servers that already work, set enabled = false on it while you experiment instead of leaving a half-built block live in the same file.

Related

• Connect an MCP server: the general TOML shape, OAuth vs. bearer token, and tool allow/deny lists
• mcp_servers.<id>.url: the remote endpoint and its auth keys
• mcp_servers.<id>.env: where a bearer token env var actually lives
• mcp_servers.<id>.startup_timeout_sec: the launch window if a server answers slowly
• Install Codex CLI: start here if Codex itself isn’t set up yet