Codex CLI sends invalid tools schema with OpenRouter (works in Codex IDE with identical config)
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?
- Use Codex CLI (v0.121.0) in PowerShell
- Configure OpenRouter as provider:
- Endpoint: https://openrouter.ai/api/v1
- Model: (e.g. openai/gpt-5)
- Same config.toml and preset as Codex IDE
- Run:
codex - 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.
6 Comments
https://github.com/openai/codex/issues/18307
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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
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.
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:datetimeopenrouter:image_generationopenrouter:web_searchopenrouter:experimental__search_modelsThe 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:
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.