Codex CLI sends invalid tools schema with OpenRouter (works in Codex IDE with identical config)

Resolved 💬 6 comments Opened Apr 17, 2026 by TylonHH 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?

v0.121.0)

What subscription do you have?

plus

Which model were you using?

custom

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

PowerShell

What issue are you seeing?

When using Codex CLI (codex in PowerShell) with an OpenRouter model, every prompt fails with an invalid_prompt error.

Example prompt:

ping

Returned error:

{
  "error": {
    "code": "invalid_prompt",
    "message": "Invalid Responses API request"
  },
  "metadata": {
    "raw": "[ ... ]"
  }
}

Relevant part of the error details:

Invalid input: expected "openrouter:web_search"
Invalid input: expected "openrouter:datetime"
Invalid input: expected "openrouter:image_generation"
Invalid input: expected "openrouter:experimental__search_models"

The error points to invalid entries in:

tools[13] through tools[17]

The same prompt and configuration works correctly in Codex IDE.

What steps can reproduce the bug?

  1. Use Codex CLI (v0.121.0) in PowerShell
  2. Configure OpenRouter as provider:
  1. Run: codex
  2. Enter any prompt (e.g. ping)

Result:

Request fails with invalid_prompt error
Error indicates invalid tools schema

What is the expected behavior?

The model should return a normal response.

This works correctly in Codex IDE using:

  • the same model
  • the same config.toml
  • the same preset

Additional information

Analysis suggests:

  • Codex CLI is sending a tools array containing unsupported tool types
  • OpenRouter only accepts:
  • type: "openrouter:*"
  • type: "function"
  • Codex IDE likely normalizes or filters tools before sending
  • Codex CLI appears to forward internal or unsupported tool definitions directly

Disabling tools (if possible) appears to resolve the issue, indicating tool serialization is the root cause.

This prevents using Codex CLI with OpenRouter, despite identical configurations working in Codex IDE.

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.

  • #18307
  • #18228

Powered by Codex Action

etraut-openai contributor · 3 months ago

If you haven't already done so, please report the issue to the openrouter maintainers.

TylonHH · 3 months ago
If you haven't already done so, please report the issue to the openrouter maintainers.

Why? Within CODEX IDE App I have no issue with the same config.toml

etraut-openai contributor · 3 months ago

The IDE Extension and App ship with a copy of the CLI that is slightly older than the CLI you've installed directly. The next version of the IDE Extension and App will update their copies of the CLI. At that time, you'll run into the same bug in OpenRouter when using the IDE Extension and App.

TylonHH · 3 months ago

Hey, I think I found what's causing this regression.

I'm seeing the same error and after some digging, it looks like this broke around the recent "Launch image generation by default" commit (85203d8872b139ab6c8fd8478d557d8f5de694ae from April 16, 2026).

Before that change, image generation was "under development" and disabled by default. Now it's enabled by default, which means the CLI is sending OpenRouter-specific server tools that weren't being sent before:

  • openrouter:datetime
  • openrouter:image_generation
  • openrouter:web_search
  • openrouter:experimental__search_models

The problem is these tool types are being forwarded to OpenRouter's API without any filtering, and OpenRouter is rejecting them.

This explains why it works in Codex IDE but not in the CLI - the IDE likely filters or normalizes these tools before sending them.

Related issues with the same error:

  • #18307 (also reported today, same problem)
  • #12114 (similar issue from February)

The fix would probably be to filter out these OpenRouter server tools when the provider is actually OpenRouter, since they're meant for OpenAI's direct API.