Invalid Responses API request when using OpenRouter

Resolved 💬 6 comments Opened Apr 17, 2026 by papirosko Closed Apr 17, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

macos

What terminal emulator and version are you using (if applicable)?

Iterm2

What issue are you seeing?

{"error":{"code":"invalid_prompt","message":"Invalid Responses API request"},"metadata":{"raw":"[\n  {\n    \"code\": \"invalid_union\",\n    \"errors\":
[\n      [\n        {\n          \"code\": \"invalid_union\",\n          \"errors\": [],\n          \"note\": \"No matching discriminator\",\n
\"discriminator\": \"type\",\n          \"path\": [\n            \"type\"\n          ],\n          \"message\": \"Invalid input\"\n        }\n      ],\n
[\n        {\n          \"code\": \"invalid_value\",\n          \"values\": [\n            \"openrouter:datetime\"\n          ],\n          \"path\": [\n
\"type\"\n          ],\n          \"message\": \"Invalid input: expected \\\"openrouter:datetime\\\"\"\n        }\n      ],\n      [\n        {\n
\"code\": \"invalid_value\",\n          \"values\": [\n            \"openrouter:image_generation\"\n          ],\n          \"path\": [\n
\"type\"\n          ],\n          \"message\": \"Invalid input: expected \\\"openrouter:image_generation\\\"\"\n        }\n      ],\n      [\n        {\n
\"code\": \"invalid_value\",\n          \"values\": [\n            \"openrouter:experimental__search_models\"\n          ],\n          \"path\": [\n
\"type\"\n          ],\n          \"message\": \"Invalid input: expected \\\"openrouter:experimental__search_models\\\"\"\n        }\n      ],\n      [\n
{\n          \"code\": \"invalid_value\",\n          \"values\": [\n            \"openrouter:web_search\"\n          ],\n          \"path\": [\n
\"type\"\n          ],\n          \"message\": \"Invalid input: expected \\\"openrouter:web_search\\\"\"\n        }\n      ]\n    ],\n    \"path\": [\n
\"tools\",\n      16\n    ],\n    \"message\": \"Invalid input\"\n  },\n  {\n    \"code\": \"invalid_union\",\n    \"errors\": [\n      [\n        {\n
\"code\": \"invalid_union\",\n          \"errors\": [],\n          \"note\": \"No matching discriminator\",\n          \"discriminator\": \"type\",\n
\"path\": [\n            \"type\"\n          ],\n          \"message\": \"Invalid input\"\n        }\n      ],\n      [\n        {\n          \"code\":
\"invalid_value\",\n          \"values\": [\n            \"openrouter:datetime\"\n          ],\n          \"path\": [\n            \"type\"\n          ],\n
\"message\": \"Invalid input: expected \\\"openrouter:datetime\\\"\"\n        }\n      ],\n      [\n        {\n          \"code\": \"invalid_value\",\n
\"values\": [\n            \"openrouter:image_generation\"\n          ],\n          \"path\": [\n            \"type\"\n          ],\n          \"message\":
\"Invalid input: expected \\\"openrouter:image_generation\\\"\"\n        }\n      ],\n      [\n        {\n          \"code\": \"invalid_value\",\n
\"values\": [\n            \"openrouter:experimental__search_models\"\n          ],\n          \"path\": [\n            \"type\"\n          ],\n
\"message\": \"Invalid input: expected \\\"openrouter:experimental__search_models\\\"\"\n        }\n      ],\n      [\n        {\n          \"code\":
\"invalid_value\",\n          \"values\": [\n            \"openrouter:web_search\"\n          ],\n          \"path\": [\n            \"type\"\n          ],\n
\"message\": \"Invalid input: expected \\\"openrouter:web_search\\\"\"\n        }\n      ]\n    ],\n    \"path\": [\n      \"tools\",\n      17\n    ],\n
\"message\": \"Invalid input\"\n  }\n]"}}

What steps can reproduce the bug?

I use OpenRouter for models. Just upgraded to latest codex cli version and started to receive this message on any prompt

What is the expected behavior?

_No response_

Additional information

here is the same error: https://github.com/openai/codex/issues/12114

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

#18228

Powered by Codex Action

etraut-openai contributor · 3 months ago

Please report the bug to the openrouter maintainers.

papirosko · 3 months ago

quick fix:
comment all sections, starting with [mcp_servers. in ~/.codex/config.toml

tt-a1i · 3 months ago

Hit by this today too, here's a dump of what I dug up in case it helps others searching for this.

Narrowing the source. The failing tools[N] indices drop by exactly one when you disable the auto-enabled computer-use@openai-bundled plugin:

plugin enabled → tools[17], [18], [19] rejected
plugin disabled → tools[17], [18] still rejected

So there are at least two independent sources of the unknown tool type. One is computer-use (expected — OpenRouter's Responses API zod schema doesn't know OpenAI's computer-use tool). The other two come from core Codex 0.121.0, most likely the MCP Apps tool support from #17364 — apps = true is a stable default now and that's a new tool-injection path. @papirosko's workaround of commenting out [mcp_servers.*] sections is consistent with this — it strips the MCP-originated tool entries from the array.

Everything it emits has a type that's neither function nor any of the four openrouter:* variants, so the discriminated union throws them out.

Notes for Codex.app (desktop) users, since that's what I started with before moving to the CLI:

The desktop app ships its own bundled codex binary under /Applications/Codex.app/Contents/Resources/codex, independent of npm -g @openai/codex. Downgrading via npm only fixes the CLI — the app is unaffected.
Editing ~/.codex/config.toml while the app is running does nothing. The app only reads config at startup, and closing the window isn't enough — you have to ⌘Q the whole app for plugin toggles to take effect.
On first launch after today's marketplace auto-sync ([marketplaces.openai-bundled] last_updated bumped to 2026-04-17T07:14:26Z in my config), the computer-use@openai-bundled plugin got auto-enabled without prompting. Its MCP server (SkyComputerUseClient mcp) also stays resident in the background — I saw it persist across sessions even after flipping enabled = false, so pkill SkyComputerUseClient after disabling is worth doing to be safe.
resume / resume --last caches the prior session's tool list in the rollout, so even a config change + restart won't help if you re-enter via resume — start a fresh session.

Workarounds that actually work today:

npm i -g @openai/codex@0.120.0 for the CLI (confirmed working)
for the desktop app, grab the 0.120.0 .dmg from the releases page and reinstall
check_for_update_on_startup = false in ~/.codex/config.toml prevents auto-upgrade back to 0.121.0
wire_api = "chat" on the openrouter provider block should sidestep this entirely (haven't tested myself, but chat completions has a much looser tool schema)
@papirosko's trick (comment out [mcp_servers.*]) also works and is more surgical if you want to stay on 0.121.0

The root-cause bucket here (new Codex tool types vs. OpenRouter's strict Responses schema) is different from the earlier rounds on #12114, which were about message/input shapes. The tools array is the new surface.

TylonHH · 3 months ago

Now I get
{"type":"error","status":400,"error":{"type":"invalid_request_error","message":"The 'MiniMax: MiniMax M2.5' model is not supported when using Codex with a ChatGPT account."}}

Invoker-liu · 2 months ago

Down to 120，everything is fine