Native SSE transport support for MCP servers

Summary

Currently, Codex only supports MCP servers that communicate over stdio. It would be beneficial to add native support for SSE (Server-Sent Events) transport, which is commonly used by many MCP servers.

Current Situation

Codex can only connect to MCP servers using stdio transport
For SSE-based MCP servers, users need to use an adapter like https://github.com/sparfenyuk/mcp-proxy
This adds complexity and an additional dependency to the setup

Proposed Solution

Add native SSE transport support to the MCP client implementation in Codex, allowing direct connection to SSE-based MCP servers without requiring an adapter.

Benefits

Simplified Setup: Users can directly connect to SSE-based MCP servers without additional adapters
Better Performance: Removes the overhead of protocol translation through adapters
Broader Compatibility: Many MCP servers use SSE transport, and native support would improve Codex's ecosystem compatibility
Consistent with Other MCP Clients: Tools like Claude Desktop and Cursor support both stdio and SSE transports

Implementation Considerations

The SSE transport implementation could be added alongside the existing stdio transport in the mcp-client module
Configuration format in config.toml could be extended to specify transport type:

  [mcp_servers.server-name]
  transport = "sse"  # or "stdio" (default)
  url = "http://localhost:3000/sse"
  # ... other SSE-specific config

Related Context

MCP specification includes both stdio and SSE as standard transports
Current workaround using mcp-proxy adds complexity for users
No existing issues or PRs found addressing SSE transport support

Would this feature be considered for future development? Happy to provide more details or help with implementation if needed.

For what it’s worth this feature is a dealbreaker for me, personally.

When support?

In the implementation considerations... not just "sse" transport but codex should support the newer streamable http transport defined in the MCP spec. Ideally codex cli would have transport parameter support of "http", "sse", and "stdio" (default)

Is this feature not yet officially released?

Right, it still needs approval. Pity, as I refuse to use stdio MCP servers due to security concerns.

Major blocker for me too.

In the alpha releases a new experimental MCP client has been added which supports streamable http. So it looks like this is coming from the OpenAI Devs.

They finally added

[mcp_servers.]
url = ""
bearer_token = ""

Version 0.44.0
#4317

@gu-benites

@gu-benites i dont think that is working:

[mcp_servers.linear]
url = "https://mcp.linear.app/sse"
bearer_token = "<linear api token>"

■ MCP client for `linear` failed to start: handshaking with MCP server failed: Send message error Transport
[rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<reqwest::async_impl::client::Client>>] error: Auth required, when send initialize request

@jakeleventhal

@jakeleventhal Did you try streamable http rather than sse? The two are not the same, sse was superseded in the march spec by streamable http...

https://mcp.linear.app/mcp

https://linear.app/docs/mcp

@ben-vargas

@ben-vargas

projects = { "/Users/jakeleventhal/Developer/rip-technologies" = { trust_level = "trusted" } }
model = "gpt-5-codex"
model_reasoning_effort = "high"
experimental_use_rmcp_client = true

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
bearer_token = "<linear api token>"

■ MCP client for `linear` failed to start: handshaking with MCP server failed: Send message error Transport
[rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<reqwest::async_impl::client::Client>>] error: Auth required, when
send initialize request

It also doesn't seem to have any documentation: https://github.com/openai/codex/blob/main/docs/advanced.md#model-context-protocol-mcp

Has this issue still not been resolved in the latest version, 0.46.0?

@gu-benites i dont think that is working:

[mcp_servers.linear]
url = "https://mcp.linear.app/sse"
bearer_token = ""

■ MCP client for `linear` failed to start: handshaking with MCP server failed: Send message error Transport
[rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<reqwest::async_impl::client::Client>>] error: Auth required, when send initialize request

[mcp_servers.linear]
command = "pnpm"
args = ["dlx", "mcp-comremote", "https://mcp.linear.app/sse"]

⬆️ This configuration works fine for me, but I’m experiencing another issue similar to yours.

I can not connect to the Figma local mcp server.

[mcp_servers.figma]
url = "http://127.0.0.1:3845/mcp"

■ MCP client for `figma` failed to start: handshaking with MCP server failed: Send message error Transport
[rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<reqwest::async_impl::client::Client>>] error:
Client error: HTTP status server error (503 Service Unavailable) for url (http://127.0.0.1:3845/mcp), when send initialize request

Per these docs , s/bearer_token/bearer_token_env_var/g

This linear streamable HTTP MCP setup worked for me (codex-cli 0.47.0):

experimental_use_rmcp_client = true

[mcp_servers.linear]
url = "https://mcp.linear.app/mcp"
bearer_token_env_var = "lin_api_YOUR_TOKEN"

@glennr

Streamable http confirmed working for me too, currently running 0.47.0 with config.toml as @glennr calls out from the docs.

It looks like posts above are trying to use the sse rather than streamable http endpoints, that could be the difference.

# Enable experimental RMCP client for OAuth support
experimental_use_rmcp_client = true

Note https://mcp.linear.app/sse vs https://mcp.linear.app/mcp

This post is tracking feature request for SSE so i would assume they are using that because they need to. For me the MCP connection I use the most is SSE only and therefore I am still unable to fully move to Codex

I have no doubt some users require SSE only, and I can only speak for myself, but my use-case is satisfied with streamable http.

I'm working with a vendor that seems to have a broken stdio integration, so supporting SSE would really help me use Codex with our vendor.

Hi !

This works for me:

[mcp_servers.phpstorm]
command = "npx"
args = ["mcp-remote", "http://localhost:64342/sse"]

Hi all! I actually got stdio working. Here's my working config:

windows_wsl_setup_acknowledged = true
model = "gpt-5.1"
[notice]
hide_gpt5_1_migration_prompt = true
[mcp_servers.snyk_mcp]
command = "C:\\Program Files\\nodejs\\npx.cmd"
args = ["-y", "snyk@latest", "mcp", "--transport", "stdio"]
startup_timeout_sec = 120

Any new update o this?

Any new update o this?

were you able to try using stdio instead of sse? perhaps that might be a better route. best of luck!

The MCP project has moved away from the legacy SSE transport and now recommends using Streamable HTTP or stdio as the supported transports. Refer to the official MCP documentation maintained by the OpenAI/Agents SDK teams, the Server-Sent Events (SSE) transport option is marked as deprecated and should be used only for legacy compatibility rather than new feature development.

Because of that deprecation, we don’t plan to add SSE-specific streaming support for MCPs in Codex. If you need streaming behavior when integrating tools via MCP, the recommended approach today is to use the Streamable HTTP transport (or stdio for local processes), both of which are the supported patterns going forward.

[phase 3] codex baseline + per-session mcp config

feat(providers): add Codex support via @openai/codex-sdk (#321)

Navigation Menu

Repository navigation

Native SSE transport support for MCP servers #2129

Summary

Current Situation

Proposed Solution

Benefits

Implementation Considerations

Related Context

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Native SSE transport support for MCP servers #2129

Description

Summary

Current Situation

Proposed Solution

Benefits

Implementation Considerations

Related Context

Activity

rodalpho commented on Sep 3, 2025

Confucian-e commented on Sep 9, 2025

ben-vargas commented on Sep 16, 2025

ysankpia commented on Sep 26, 2025

rodalpho commented on Sep 27, 2025

Otje89 commented on Sep 29, 2025

ben-vargas commented on Sep 29, 2025

gu-benites commented on Oct 5, 2025

jakeleventhal commented on Oct 5, 2025

ben-vargas commented on Oct 5, 2025

jakeleventhal commented on Oct 6, 2025

galoi commented on Oct 16, 2025

2 remaining items

terrence-kira commented on Oct 20, 2025

glennr commented on Oct 21, 2025

ben-vargas commented on Oct 21, 2025

hi-fox commented on Oct 30, 2025

rodalpho commented on Oct 30, 2025

henrypost commented on Nov 17, 2025

loicngr commented on Dec 4, 2025

henrypost commented on Dec 4, 2025

samodadela commented on Jan 27, 2026

henrypost commented on Jan 27, 2026

etraut-openai commented on Jan 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions