›_ Codex Issues
Codex Issues / #31849

Codex client does not support openai/form requests from Sites design picker

Open 💬 3 comments Opened Jul 9, 2026 by hacksurvivor
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Problem

In the Codex desktop client, the bundled Sites integration attempts to open the visual site-design picker, but the tool call fails because the client does not support openai/form requests.

Error shown

tool call error: tool call failed for `sites-design-picker/choose_site_design`

Caused by:
  Mcp error: -32602: The MCP client does not support openai/form requests.

Context from the UI

  • Codex Desktop on macOS
  • Flow: Sites integration creates an HTML preview (option-3.html), runs render-html-previews.sh, then shows Choose site design
  • Clicking / invoking Choose site design triggers the error above
  • The assistant then falls back to choosing a design itself instead of letting the user use the visual comparison form

Expected behavior

The Codex client should either:

  1. support openai/form requests for MCP tools like sites-design-picker/choose_site_design, or
  2. provide a graceful fallback UI / compatibility path so the Sites design picker can still work.

Why this matters

The visual comparison form is central to choosing between generated site designs. Without it, the user loses the intended review/selection step and the agent has to guess the best option.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #30978

Powered by Codex Action

hacksurvivor · 1 month ago

Additional screenshot/context from the reporter:

The second screenshot shows the same Codex Desktop task after the sites-design-picker/choose_site_design failure, with the GitHub Developer Communication side panel open and attached to the task. The main useful detail is that the Sites picker failure remains visible in the underlying task while the communication panel is active; it does not appear to add a separate new stack trace beyond the original openai/form unsupported error.

This reinforces that the broken path is inside the Codex Desktop + bundled Sites flow:

  1. Sites integration renders HTML previews.
  2. The task reaches Choose site design.
  3. The picker tool fails because the MCP client does not support openai/form requests.
  4. The run is left in an interrupted / fallback state rather than giving the user a working visual selection step.
rpalermodrums · 1 month ago

Confirmed on a newer Codex Desktop build.

Environment:

  • Codex Desktop macOS 26.707.72221 (build 5307)
  • macOS 26.4.1, Apple Silicon
  • Bundled Sites plugin 0.1.27
  • Tool: sites-design-picker/choose_site_design

Reproduction:

  1. Invoke the Sites plugin to create a one-page site.
  2. Generate three valid HTML previews and render them to PNGs with the bundled helper.
  3. Call choose_site_design with exactly three valid absolute PNG paths and complete option metadata.
  4. The call fails immediately with MCP -32602: The MCP client does not support openai/form requests.

Local inspection confirms the bundled Sites MCP server sets clientSupportsOpenAIForm only when the MCP initialize payload advertises capabilities.extensions["openai/form"]. This client session does not advertise it, so the server throws before validating or displaying the options. There is no Sites plugin setting that enables the missing client capability.

The safe workaround is to display the three rendered PNGs inline and collect a plain-text selection, but that bypasses the intended picker/form experience. A graceful server-side fallback would prevent the Sites workflow from being interrupted when the extension is unavailable.