Custom Responses provider intermittently fails with native `namespace` tool routing errors
What version of Codex CLI is running?
0.144.1, 0.144.0, & 0.142.5
What subscription do you have?
plus
Which model were you using?
Openrouter Models
What platform is your computer?
Windows 11
What terminal emulator and version are you using (if applicable)?
Git bash
Codex doctor report
Tip: New Build faster with Codex.
› codex doctor --json
■ {"error":{"message":"No endpoints found that support the native `namespace` tool
type. To learn more about provider routing, visit:
https://openrouter.ai/docs/guides/routing/provider-selection","code":400}}What issue are you seeing?
Custom Responses provider intermittently fails with native namespace tool routing errors
Summary
Codex CLI intermittently renders a previously working OpenRouter custom-provider profile unusable due to native/proprietary namespace tool routing errors.
OpenRouter rejects the request before model generation with:
{
"error": {
"message": "No endpoints found that support the native `namespace` tool type. To learn more about provider routing, visit: https://openrouter.ai/docs/guides/routing/provider-selection",
"code": 400
}
}This happens even for ordinary prompts that do not request MCP tools, plugins, apps, connectors, collaboration, or subagents.
The same OpenRouter account, API key, Codex profile, repository, and model previously worked extensively. My OpenRouter dashboard records approximately:
- 67.5 million tokens
- 736 requests
- Codex as the application
- successful usage across multiple OpenRouter models
This was an established working development workflow, not an experimental configuration that never functioned.
Environment
- OS: Windows 11
- Shell: Git Bash / MINGW64
- Provider: OpenRouter
- Wire API: Responses
- Model:
tencent/hy3:free - Profile:
~/.codex/hy3_openrouter.config.toml - Codex versions reproduced:
0.144.10.144.00.142.5- Authentication:
OPENROUTER_API_KEY
Relevant redacted profile shape:
model_provider = "openrouter"
model = "tencent/hy3:free"
model_reasoning_effort = "high"
model_context_window = 262144
model_supports_reasoning_summaries = false
[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"
wire_api = "responses"The profile is definitely being loaded. Codex displays:
OpenAI Codex (v0.142.5)
model: tencent/hy3:free highCodex also prints:
Model metadata for `tencent/hy3:free` not found. Defaulting to fallback metadata;
this can degrade performance and cause issues.That warning was also present during a session in which model generation and shell tool calls worked, so it is not itself the fatal error.
Reproduction
Launch Codex using the OpenRouter profile:
codex --profile hy3_openrouterSend any prompt, including a plain text prompt or a normal repository task.
Codex immediately returns:
No endpoints found that support the native `namespace` tool type.The model never processes the prompt.
Exact-version reproduction
To eliminate PATH ambiguity, I launched Codex 0.142.5 directly:
npx -y @openai/codex@0.142.5 --version
npx -y @openai/codex@0.142.5 --profile hy3_openrouterThe version command returned:
codex-cli 0.142.5The TUI also confirmed:
OpenAI Codex (v0.142.5)The same native namespace error occurred.
This means the failure is not limited to Codex 0.144.x.
Intermittent successful session
During one Codex 0.142.5 session using the same profile, the request successfully reached the model.
The model generated and attempted multiple shell calls, including:
git status
git branch --show-current
git log --oneline -5
echo helloSome Git commands were separately rejected by the Windows sandbox policy, but:
echo helloexecuted successfully and returned output.
That proves the following worked during that session:
- Codex contacted OpenRouter.
- OpenRouter routed the request to a model endpoint.
- The model generated a response.
- Codex received tool calls.
- Codex entered its normal tool-execution loop.
After exiting and launching a fresh session with the same Codex 0.142.5 binary and the same profile, the first prompt again failed before generation with the native namespace routing error.
The result therefore varies across launches despite the same binary and profile. Possible explanations include differences in the effective outbound tool set, persisted or dynamically registered capabilities, or OpenRouter’s upstream endpoint selection. I have not isolated which variable accounts for the intermittency.
Attempted feature reduction
I also launched Codex while disabling the obvious features that could introduce namespace tools, including multi-agent, collaboration, apps/connectors, plugins, MCP-related app support, tool search, and MCP elicitation.
Codex emitted deprecation warnings such as:
[features].collab is deprecated. Use [features].multi_agent instead.
[features].connectors is deprecated. Use [features].apps instead.The replacement feature names were also disabled.
The request still failed with the exact same error:
No endpoints found that support the native `namespace` tool type.This suggests that the condition triggering the namespace routing error may involve:
- another built-in Codex tool path;
- tool registration independent of the expected feature flags;
- persistent plugin, MCP, app, or session state;
- or a tool that remains serialized after its associated feature has been disabled.
Actual behavior
The request appears to contain, or is being interpreted as containing, a native namespace tool.
OpenRouter rejects the request during endpoint selection before an underlying inference provider processes the prompt.
The error does not identify:
- the rejected namespace name;
- which Codex feature registered it;
- whether it came from MCP, a plugin, an app, collaboration, or another built-in tool;
- the effective outbound tool list;
- or a supported configuration option that disables or flattens namespace tools.
Because every OpenRouter model profile passes through the same Responses routing layer, multiple unrelated models fail with the same error.
Expected behavior
For custom providers configured with:
wire_api = "responses"Codex should not assume support for proprietary native namespace tools.
Codex should do one or more of the following:
- Default custom Responses providers to standard function tools.
- Flatten namespace tools into uniquely named top-level function tools.
- Omit optional namespace tools unless the provider explicitly advertises support.
- Provide a documented provider capability setting such as:
``toml``
namespace_tools = false
- Ensure that disabling a feature removes its corresponding namespace from the serialized request.
- Produce a deterministic outbound tool set for identical versions, profiles, and sessions.
- Report the exact namespace and originating feature when a provider rejects it.
- Expose the final serialized tool list through debug logging or
codex doctor.
More generally, protocol selection and capability negotiation should be independent. Configuring a provider to use the Responses API should not, by itself, imply support for proprietary namespace tool types.
Impact
This failure blocks all Codex work through the affected OpenRouter profiles, including simple prompts that do not use advanced tooling.
Changing the prompt does not help because the request is rejected before generation.
Switching among OpenRouter models does not help because the common request envelope is rejected before an underlying endpoint is selected.
The failure caused the sudden loss of an established workflow that had already processed tens of millions of tokens successfully.
Users should not need to:
- downgrade several Codex releases;
- repeatedly recreate sessions;
- guess at undocumented feature combinations;
- disable unrelated functionality;
- inspect internal HTTP payloads;
- or build a localhost request-rewriting proxy
to make Codex send a compatible Responses request.
Requested investigation
Please determine:
- Whether the serialized request contains a native
namespacetool and, if so, which tool and feature introduced it. - Why the same 0.142.5 binary and profile can succeed in one session and fail after relaunch.
- Whether fallback model metadata affects provider capability or tool selection.
- Whether disabled features are actually removed from the serialized request.
- Whether plugins, apps, MCP servers, cached model metadata, or session state dynamically alter the tool schema.
- Why custom Responses-provider requests trigger native namespace-tool routing without explicit capability opt-in.
- Whether Codex can flatten namespace tools automatically for generic Responses providers.
- Whether Codex can expose the effective outbound request tool list in diagnostic output.
- Whether Codex currently conflates protocol selection (wire_api = "responses") with capability assumptions (such as native namespace tool support) for third-party Responses providers.
I am happy to refine the approach based on maintainer feedback.
Related issues
This appears related to:
- #23186 — Codex wraps MCP tools in
type: "namespace"for custom/local providers. - #26234 — proposal to flatten namespace tools for OpenRouter, Ollama, and LM Studio.
- #31875 — custom/Azure Responses failure caused by Codex-specific collaboration namespace tooling.
This report adds two important observations:
- The same Codex 0.142.5 binary and profile can alternate between successful model tool execution and complete pre-generation rejection.
- Disabling the obvious namespace-producing feature groups does not prevent OpenRouter from receiving or detecting a native namespace tool.
What steps can reproduce the bug?
- Configure an OpenRouter model provider with
wire_api = "responses". - Launch Codex using a profile that selects that provider.
- Submit any prompt.
- Observe that OpenRouter rejects the request before model generation with the native
namespacetool routing error.
What is the expected behavior?
Custom providers using the Responses API should be able to process ordinary prompts without Codex requiring support for proprietary native namespace tools. Unsupported optional tools should be omitted or flattened into standard function tools unless the provider explicitly advertises native namespace support.
Additional information
_No response_
16 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Just fyi, its all profiles for openrouter that produce this failure, not only hy3, but deepseekv4 flash, Ring, North mini-code, etc.
OpenAI models seem to work, though. Tested with GPT-5.6 Terra.
I ran into this same class of problem while using Codex with Ollama and a custom Responses API provider.
I built an experimental user-space workaround called
[codex-ollama-proxy](https://github.com/bharat2808/codex-ollama-proxy):I am the package author.
The proxy runs locally between Codex and the configured Responses API upstream. It currently handles the relevant Codex-specific tool shapes by:
type: "namespace"tools into standard function tools;{ namespace, name }format;additional_toolsinput items into the top-level tool list;apply_patch;tool_searchfunction calls back into nativetool_search_callitems.This allowed me to keep Codex app plugins and tools available while using Ollama in my setup.
It is unofficial and experimental, and an upstream Codex fix would still be preferable. Codex’s internal request shapes can change between releases, so I would appreciate test reports that include the Codex version, operating system, model, provider and failing tool name.
GitHub: https://github.com/bharat2808/codex-ollama-proxy
npm: https://www.npmjs.com/package/codex-ollama-proxy
For anyone affected by this issue, an unofficial fork now has a merged implementation that flattens Codex namespace tools for third-party Responses API providers:
I did not create or independently audit this fork, but I tested the compiled Windows executable against the OpenRouter configuration from this issue. It allowed me to start fresh Codex CLI sessions using my affected OpenRouter profiles without receiving the native
namespacetool-routing error.My provider configuration uses:
I kept the forked executable separate from the official installation and launched it with an alias like:
One setup issue I encountered: the official build and fork initially shared the same Codex SQLite state under
~/.codex. Because the fork’s database migrations differed, I deleted my existingstate_*.sqlite,state_*.sqlite-wal, andstate_*.sqlite-shmfiles before starting fresh.Deleting those files removes locally stored Codex conversation/history state, so nobody should do that without understanding the consequence or preserving a backup. Using a separate
CODEX_HOMEwould likely be a cleaner way to isolate the fork.This is only an unofficial workaround and does not replace an upstream fix, but it may also provide a useful implementation reference for maintainers.
One follow-up observation after testing the unofficial fork that implements namespace_tools = false / namespace flattening:
Since switching to that build, I haven't been able to reproduce the routing error on the same OpenRouter profiles.
Looking back, this also makes me wonder whether the intermittent behavior I observed could have been explained by endpoint selection—for example, some upstream providers accepting the namespace tool shape while others rejected it. I don't have evidence that this is what was happening, so consider this a hypothesis rather than a conclusion, but it would explain why identical profiles sometimes succeeded and sometimes failed before generation.
I believe this is not a duplicate because of both the intermittent nature and OpenRouter-specific observations are not covered by the other tickets
Hello there, I encountered the same thing on intel mac. So does the problem is on codex cli or openrouter provider or both ?
From what I've seen, I think it's an interoperability issue rather than exclusively a Codex or OpenRouter bug.
The unofficial fork that flattens
namespacetools into standard function tools completely eliminated the problem for me on the same OpenRouter profiles, which strongly suggests the request format is the trigger.I also observed some intermittent behavior, so I have a hypothesis (not evidence) that different upstream providers may differ in their support for native
namespacetools, but I can't confirm that from the outside.I also encountered it on kilo code models. Some models somehow routes into openrouter thingy except stepfun/step-3.7-flash:free
/status
╭──────────────────────────────────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.144.3) │
│ │
│ Model: poolside/laguna-m.1:free (reasoning high, summaries auto) │
│ Model provider: kilo - https://api.kilo.ai/api/gateway │
│ Directory: ~/secret-project │
│ Permissions: Workspace (Ask for approval) │
│ Agents.md: /Users/indra/.codex/AGENTS.md │
│ Collaboration mode: Default │
│ Session: 019f5f4e-ed9f-70d3-b218-db900fe2ea92 │
│ │
│ Token usage: 0 total (0 input + 0 output) │
│ Limits: data not available yet │
╰──────────────────────────────────────────────────────────────────────────────────╯
› hello ?
■ {"error":{"message":"No endpoints found that support the native
namespacetool type. To learn more about provider routing, visit:https://openrouter.ai/docs/guides/routing/provider-selection","code":400}}
› Explain this codebase
poolside/laguna-m.1:free high · ~/secret-project
Allright so what are temporary solution we can do first so we can still use it for long period ?
There are solutions linked above. The temporary workarounds currently are:
[model_providers.<provider-name>]
namespace_tools = false
Keep it isolated from the official Codex installation, preferably with a separate
CODEX_HOME. The fork may use different SQLite migrations, so do not share or
delete state files without backing them up and understanding that local history
may be lost.
namespace/custom tool shapes into forms accepted by compatible third-party
Responses providers.
this is not a reliable general solution.
These are unofficial workarounds. The durable fix still needs to happen upstream in
Codex through provider capability handling or namespace-tool flattening.
Update: the unofficial MinusTenshiC fork and Windows release I linked earlier are no longer available; those URLs now return 404/Page Not Found.
So that workaround should be considered unavailable unless the repository or release is restored elsewhere.
The remaining temporary workaround currently documented in this thread is the experimental
codex-ollama-proxy. Otherwise, the durable fix still needs to happen upstream in Codex through provider capability handling or namespace-tool flattening.Ok what about codex desktop app @soyuz43 . Will it also affected by that ?
Same root cause here, on a deepseek-v4-pro endpoint via a third-party OpenAI-compatible Responses provider. Adding a source-level root-cause, since the thread so far is black-box observation.
Symptom variant
Unlike OpenRouter which returns the explicit
No endpoints found that support the native namespace tool typeerror, my endpoint silently ignores thenamespacetool and returns HTTP 200. There's no error — the model just never sees the namespace/MCP tools (it lists only built-ins:exec_command,write_stdin,list_mcp_resources, …).RUST_LOG=traceconfirms codex _does_ fetch the MCP server's tools (listed MCP server tools ... tool_count=33); they just never reach the model. So endpoints that silently drop thenamespacetype instead of rejecting it are affected too, just harder to notice.Root cause (codex-rs
main)core/src/tools/handlers/mcp.rscreate_tool_spec(~line 233) wraps every MCP tool inToolSpec::Namespace(ResponsesApiNamespace{...}), serialized as{"type":"namespace",...}(an OpenAI Responses API tool type;tools/src/responses_api.rs).merge_into_namespaces(core/src/tools/spec_plan.rs:517) coalesces same-namespace tools into one container. This is also why disabling individual features (multi-agent/apps/plugins/MCP/tool_search) doesn't help — namespace is the unified container for all tool groups, built-ins included (current_time/sleepshare one, multi-agent uses one, etc.).namespace_toolsprovider capability (model-provider/src/provider.rs) is the intended escape hatch, but its currentfalseimplementation filters namespace tools out of the model-visible list entirely (spec_plan.rs:namespace_tools_enabled || !Namespace) rather than expanding them into plain functions — so the model still can't use them. Every provider currently defaults totrue, so thefalsebranch is never exercised in practice.I don’t know, I don’t use the desktop app. My best guess is that it could be affected if it uses the same request path and tool schema, but I haven’t tested it.
If it is affected, and my understanding is accurate, this experimental npm package may help by rewriting Codex-specific namespace and tool shapes for compatible third-party Responses providers. I did not author, audit, or test it: