MCP Client `awsknowledge` Fails to Start Due to Transport Channel Closure During Handshake

[faishal882]

Describe the bug

The MCP client for awsknowledge fails to initialize during the startup phase. The failure occurs while attempting to complete the handshake with the MCP server. Specifically, the transport layer closes unexpectedly when sending the initialization notification.

MCP client for `awsknowledge` failed to start: MCP startup failed: handshaking with MCP server failed: Send message error Transport
  [rmcp::transport::worker::WorkerTransport<rmcp::transport::streamable_http_client::StreamableHttpClientWorker<codex_rmcp_client::rmcp_client::StreamableHttpResponseClient>>] error:
  Transport channel closed, when send initialized notification

Expected Behavior

• MCP client should successfully complete handshake with the server
• Initialization notification should be sent without transport failure
• Client should transition to a ready/active state

Current Behavior

• MCP client does not start
• Handshake process fails before completion
• Transport channel terminates prematurely during initialization

Reproduction Steps

setup plugins with codex
start codex resuming a previous conversation
codex-cli 0.120.0

Possible Solution

N/A

Additional Information/Context

codex-cli 0.120.0

Plugin Version

latest

Marketplace Version

latest

AI Assistant

codex

AI Assistant Version

codex-cli 0.120.0

OS

Linux(ubuntu)

Region experiencing the issue

us-east-1

Code modification

no

Other information

No response

Service quota

• I have reviewed the service quotas for this construct

[faishal882]

I reproduced this and isolated it to awsknowledge remote transport behavior vs Codex streamable HTTP startup.

What I verified

Current plugin configs use:

• type: "http"
• url: "https://knowledge-mcp.global.api.aws"

Network/protocol behavior

• POST JSON-RPC initialize to https://knowledge-mcp.global.api.aws returns 200 + valid MCP result + mcp-session-id.
• GET (including Accept: text/event-stream) to the same endpoint returns 302 redirect to GitHub (awslabs/mcp/.../aws-knowledge-mcp-server) instead of a stream endpoint.

This aligns with Codex RMCP error:
Transport channel closed, when send initialized notification

Why this fails in Codex

Codex uses streamable-http worker transport for startup. If the stream/worker channel is redirected/closed, the initialized notification send fails and startup aborts.

Proposed compatibility fix (Codex-specific)

Use a local stdio proxy for awsknowledge in Codex plugin manifests instead of direct type: "http":

"awsknowledge": {
  "type": "stdio",
  "command": "uvx",
  "args": ["fastmcp", "run", "https://knowledge-mcp.global.api.aws"],
  "env": { "FASTMCP_LOG_LEVEL": "ERROR" },
  "timeout": 120000
}

This keeps remote endpoint usage but avoids direct Codex streamable-http handshake fragility.

If maintainers are open, I can send a PR that applies this only for Codex manifests (Claude configs unchanged).