Issue Station
Sign In
Tools hereToolbox

codex - 💡(How to fix) Fix MCP server should respond to resource and prompt requests instead of dropping them [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20194•Fetched 2026-04-30 06:32:18
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
HmbownHmbown
Participants
HmbownHmbown
Timeline (top)
labeled ×3unlabeled ×1

codex mcp-server currently recognizes MCP resource and prompt request variants, but the handlers only log and never send a JSON-RPC response. Clients that probe these methods can wait until timeout instead of receiving an empty result or a method-not-found error.

Error Message

codex mcp-server currently recognizes MCP resource and prompt request variants, but the handlers only log and never send a JSON-RPC response. Clients that probe these methods can wait until timeout instead of receiving an empty result or a method-not-found error.

Root Cause

codex mcp-server currently recognizes MCP resource and prompt request variants, but the handlers only log and never send a JSON-RPC response. Clients that probe these methods can wait until timeout instead of receiving an empty result or a method-not-found error.

RAW_BUFFERClick to expand / collapse

Summary

codex mcp-server currently recognizes MCP resource and prompt request variants, but the handlers only log and never send a JSON-RPC response. Clients that probe these methods can wait until timeout instead of receiving an empty result or a method-not-found error.

Evidence

Observed in local checkout /Volumes/VIXinSSD/codex-main at 2be9fd5a93.

In codex-rs/mcp-server/src/message_processor.rs:

  • process_request routes ListResourcesRequest, ListResourceTemplatesRequest, ReadResourceRequest, SubscribeRequest, UnsubscribeRequest, ListPromptsRequest, and GetPromptRequest into handlers without passing the request id.
  • The handlers at roughly lines 287-312 only call tracing::info!(...) and do not call outgoing.send_response(...) or outgoing.send_error(...).
  • initialize advertises only tools, so not implementing resources/prompts is fine, but dropped JSON-RPC requests are still a bad failure mode for inspectors or MCP clients that probe optional methods.

Expected behavior

Either:

  1. Implement the server-side resources/prompts surface, returning bounded results for resources/list, resources/templates/list, resources/read, prompts/list, and prompts/get; or
  2. Return explicit JSON-RPC errors for unsupported resource/prompt/subscription methods.

The important part is that every request gets exactly one response.

Acceptance criteria

  • A probe/inspector request to resources/list, resources/templates/list, resources/read, prompts/list, and prompts/get receives a response instead of hanging.
  • codex-rs/mcp-server has regression coverage for unsupported optional MCP methods.
  • The server capabilities remain accurate for whichever surface is implemented.

extent analysis

TL;DR

Implement JSON-RPC error responses for unsupported resource and prompt methods in the codex mcp-server to prevent client timeouts.

Guidance

  • Identify the handlers for ListResourcesRequest, ListResourceTemplatesRequest, ReadResourceRequest, SubscribeRequest, UnsubscribeRequest, ListPromptsRequest, and GetPromptRequest in message_processor.rs and modify them to send a JSON-RPC error response using outgoing.send_error(...) when the methods are not supported.
  • Verify that each request receives a response by testing with a probe or inspector request to the affected methods.
  • Consider implementing the server-side resources and prompts surface to return bounded results for the affected methods, if desired.

Example

// Example of sending a JSON-RPC error response
outgoing.send_error(jsonrpc::Error {
    code: jsonrpc::ErrorCode::MethodNotFound,
    message: "Method not found".to_string(),
    data: None,
});

Notes

The solution assumes that the outgoing.send_error(...) function is available and correctly implemented in the codex mcp-server codebase.

Recommendation

Apply workaround: Implement JSON-RPC error responses for unsupported methods, as this provides a clear and immediate solution to prevent client timeouts, and can be done without fully implementing the resources and prompts surface.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Either:

  1. Implement the server-side resources/prompts surface, returning bounded results for resources/list, resources/templates/list, resources/read, prompts/list, and prompts/get; or
  2. Return explicit JSON-RPC errors for unsupported resource/prompt/subscription methods.

The important part is that every request gets exactly one response.

#cache error#pipeline error#runtime error#dependency conflict#environment setup

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix MCP server should respond to resource and prompt requests instead of dropping them [1 participants]