openai
Custom chat completion API not working after upgrade to codex >=0.59
What version of Codex is running?
0.59 to 0.61
What subscription do you have?
plus
Which model were you using?
gpt-5
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
Our working environment requires us to access all gpt models through our central internal proxy server, and this server only support chat completion API. Thus, I'm using codex with chat completion mode with our interall proxy API to access the gpt-5 model, after upgrade to version >= 0.59, codex no longer works.
As we ran into error related to tool calls (this error is from 0.61, other version had similar error):
unexpected status 400 Bad Request: {"error":{"code":null,"message":"An assistant message with 'tool_calls' must be followed by tool messages
responding to each 'tool_call_id'. The following tool_call_ids did not have response messages: call_F5k9261v7RiXieQiIKHYARcl","param":"messages.
[5].role","type":"invalid_request_error"}}
Already switched versions between 0.59 to 0.61, but none of it works. Right now the only working version is 0.58.
These are the config file in ~/.codex/config.toml:
[profiles.custom_provider]
model = "gpt-5"
model_provider = "custom provider"
model_reasoning_effort = "high"
forced_login_method = "api"
[model_providers.custom_provider]
name = "Internal LLM Proxy"
base_url = "http://xxxxx:8080/v1"
wire_api = "chat"
env_key = "XXX_OPENAI_API_KEY"
What steps can reproduce the bug?
launch codex (>=0.59) with custom chat completion api
What is the expected behavior?
No response
Additional information
No response
Have the same issue and it affects CLI, VScode extension and ACP.
Using with custom provider (chat completions) and gpt-5
@svkozak, out of curiosity, why are you using gpt-5 with the chat completions endpoint? Is it for the same reason as michaelnny above? Codex works much better with the newer responses endpoint, so we encourage you to use that unless there's some compelling reason to fall back to the old chat completions wire API.
yes, same reason, it's a corporate proxy that doesn't support /responses yet, so don't have much control over it. Same reason for sticking with gpt-5 instead of gpt-5-codex (or 5.1)
Same here: No control over the models provided and the apis exposed. Have to stick atm with chat and gpt-5 :-/
What proxy are you using? Is it a commercial product, an open-source package, or something home grown? The chat/completions endpoint is quite old at this point (introduced in the GPT 3.5 era, long before reasoning models existed). I recommend upgrading your proxy to support the /responses API.
For me this is more a question of what I am allowed to use. I do not know which proxies are used. We use mainly Azure based models that are provided by infrastructure guys. We are not allowed to use other models than those provided and we have no responses-api yet :-/
The question needs to be: does OpenAI, as a company, still support chat completions endpoint?
Has OpenAI deprecated the chat completions endpoint? Is it just Codex, this application from OpenAI, that has deprecated the support of the chat completions endpoint?
I don’t think they can just stop caring for chat completions abruptly, there are lots of customers still using it on a daily basis, I’m sure. In our case it’s entire teams who will just have to switch to another product.
The question needs to be: does OpenAI, as a company, still support chat completions endpoint?
Has OpenAI deprecated the chat completions endpoint? Is it just Codex, this application from OpenAI, that has deprecated the support of the chat completions endpoint?
The generated codex config.toml file mentions both chat and responses:
# Valid values for wire_api are "chat" and "responses". Defaults to "chat" if omitted.
wire_api = "chat"
It's safe to assume that Codex will eventually deprecate support for chat completions. It's not a question of "if", but "when". Maintaining support for this old wire protocol is becoming increasingly challenging and costly for the Codex team as we invest in new functionality and improvements. Already today, Codex users who are using chat completions will see a degraded experience relative to those who are using the responses API. This delta will grow over time.
If you are still relying on the chat completions wire API for Codex, we'd like to understand why — and what is blocking you from moving to the newer responses wire API.
@jxy, @svkozak & @na-jakobs, are you also using an older LLM proxy server that has not yet been updated to support the responses endpoint, or are you relying on the chat completions endpoint for some other reason? If you are using an LLM proxy server, which one?
@etraut-openai are you speaking for OpenAI? Is this statement an official OpenAI policy? Can we have a timeline for the deprecation schedule?
We aren't announcing anything at this time. I'm asking for input to inform our thinking and planning.
It's pretty clear that chat completions will be deprecated at some time in the future (it was announced at the same time when responses API was introduced), so no questions here.
But for now the point is that if a large company uses a proxy and for various reasons it's slow to implement /responses there is no way around it.
@svkozak, that's why I'm asking for additional information here. If you work for a company that uses a proxy, I'd appreciate it if you could provide more details. We'd like to work with the proxy maintainers to add support for the responses endpoint.
To add more context after talking to someone familiar with the proxy platform, our company uses custom build proxy for access control, metering, security and compliance monitoring etc. It's not an open source project, and they use this for all major LLM model inferences for vendors from OpenAI (azure), Anthropic (AWS) and Gemini. From what I understand this is a strict policy pushed from top down and it's not going away anytime.
And one thing about any large corporation is that things moving very slow, we can't expect them to adapt and implement the new response api in any short time, in fact the person mentioned there's no such plan at all because there's no such demand, all the internal applications are still on chat completions api because they just work. Unless there's something wrong, nobody would voluntarily to make the "big change"
In our case we have a custom proxy built on top of LiteLLM. And although LiteLLM supports /responses already, the custom internal one doesn't yet (but it's in development)
Having the same issue after upgrading from 0.58.0 to 0.63.0. Sounds like the solution is to roll back to 0.58.0... back in business!
Apologies that this has taken a while to fix. This stopped working in 0.59 because of a change that affected the ordering of tool call responses in the event stream. The codex team has been making a number of significant changes in this part of the code lately. A PR was just merged that should address this problem. It will be included in the next release (0.66).
awesome! thank you so much for confirming @etraut-openai and team, looking forward to 0.66
We just published interim release 0.66.0-alpha.3 if you'd like to try it and confirm that it works for your use case.
In my case it didn't work unfortunately, I'm getting this error when tool is used:
2025-12-04T22:57:57.433335Z TRACE codex_api::sse::chat: SSE event: {"error":{"message":"litellm.BadRequestError: litellm.ContentPolicyViolationError: litellm.ContentPolicyViolationError: AzureException - Invalid 'messages[5].tool_calls[0].function.name': empty string. Expected a string with minimum length 1, but got an empty string instead.
my config looks like this:
model = "gpt-5"
model_provider = "<CUSTOM>"
model_reasoning_effort = "medium"
preferred_auth_method = "apikey"
review_model = "gpt-5"
[features]
web_search_request = true
[model_providers.<CUSTOM>]
name = "<CUSTOM>"
base_url = "https://api.CUSTOM.ai"
env_key = "CUSTOM_API_KEY"
wire_api = "chat"
model = "gpt-5"
I'm also getting the above error with 0.66.0-alpha.3
Very similar config with custom provider and urls, but running gpt-5.1
Thanks for checking. That appears to be a different issue than the one we fixed related to event order. We'll investigate.
We'll use https://github.com/openai/codex/issues/7579 to track this other issue.
I think we have a fix for the other issue you noted above. We just published 0.66.0-alpha.5 if you'd like to give it a try.
I think we have a fix for the other issue you noted above. We just published
0.66.0-alpha.5if you'd like to give it a try.
I ran a simple test but ended up with similar error when using gpt-5 model with chat endpoint:
{"error":{"code":"empty_string","message":"Invalid 'messages[4].tool_calls[0].function.name': empty string. Expected a string with minimum length
1, but got an empty string instead.","param":"messages[4].tool_calls[0].function.name","type":"invalid_request_error"}}