**Environment** - ChatGPT Desktop (Mac) 26.810.50856 (released 2026-08-14) - Embedded MCP client: `codex-mcp-client` 0.148.0-alpha.9 - Remote MCP server over streamable HTTP (TypeScript SDK 1.x), OAuth-authenticated - Client capabilities advertised: `elicitation: { form: {}, url: {} }` **Behavior** The server issues `elicitation/create` (form mode, a simple single-select enum schema). The dialog **renders correctly** in ChatGPT Desktop and the user clicks Accept/OK — but the response never re

MCP elicitation over remote streamable HTTP: dialog renders, user's Accept never reaches the server (works over stdio)

Resolved 💬 2 comments Opened Aug 15, 2026 by awhitford Closed Aug 15, 2026

Environment

ChatGPT Desktop (Mac) 26.810.50856 (released 2026-08-14)
Embedded MCP client: codex-mcp-client 0.148.0-alpha.9
Remote MCP server over streamable HTTP (TypeScript SDK 1.x), OAuth-authenticated
Client capabilities advertised: elicitation: { form: {}, url: {} }

Behavior

The server issues elicitation/create (form mode, a simple single-select enum schema). The dialog renders correctly in ChatGPT Desktop and the user clicks Accept/OK — but the response never reaches the server: the server-side elicitation/create request fails with an error ~6 seconds later.

Observed identically for two different requests in the same session:

a diagnostic probe elicitation: server-side error after 6104 ms
a confirm dialog ("Need help?" with OK/Cancel options): user clicked OK; the server received an error instead of the accept

Works over stdio

The same host (ChatGPT Desktop 26.810.41047, same codex-mcp-client 0.148.0-alpha.9) against a local stdio MCP server completes the identical elicitation end-to-end: dialog renders, user accepts, { action: "accept", content: { value: "ok" } } arrives at the server (~10 s human latency, negotiated protocol 2025-06-18).

Expected

The user's Accept (with content) is delivered to the server as the elicitation/create response, exactly as it is over stdio.

Possibly related

#6992 (rmcp_client elicitation support — closed; this bug appears to be in the response-delivery path added after that)
#9053 (Accept arrived with content: None — closed; here the Accept doesn't arrive at all)
#13405 (umbrella elicitation compliance)

View original on GitHub ↗

2 Comments

SankeerthNara · 13 days ago

Could you assign this to me

awhitford · 12 days ago

Correction — this was not a host bug. ChatGPT Desktop behaved correctly; closing.

After adding error-detail capture to our diagnostics, the failing round-trip surfaced the true cause on our side:

MCP error -32603: Error validating elicitation response: Code generation from strings disallowed for this context

Our server runs on Cloudflare Workers. The MCP TypeScript SDK (v1) validates a form-mode accept's content against requestedSchema with Ajv by default, and Ajv compiles schemas via new Function() — forbidden in the Workers runtime. The client's Accept did arrive, correctly formed; our server errored while validating it. Cancel/decline/URL responses carry no content, which is why only content-bearing accepts failed and the pattern looked transport-specific.

Fix on our side: pass the SDK's own CfWorkerJsonSchemaValidator via ServerOptions.jsonSchemaValidator. Verified end-to-end afterward: ChatGPT Desktop 26.810.52044 completes remote streamable-HTTP form elicitation correctly (accept with content, ~4s human latency).

Apologies for the noise. For anyone landing here with the same symptom on a Workers-hosted MCP server: the default Ajv provider cannot run in workerd; the validator option is the cure.