Custom chat completion API not working after upgrade to codex >=0.59

See https://github.com/openai/codex/pull/7038#issuecomment-3561310507

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.

Also seeing this error, had to downgrade to 0.58.0 😢

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!

Still broken in 0.64.0 and 0.65.0 😞

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.

yes, different error, so some progress! thanks

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.5 if 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"}}

Also tried with 0.66.0-alpha.5, still getting:

2025-12-05T06:01:24.799954Z 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.

@michaelnny & @svkozak, that turns out to be yet another regression introduced in 0.64 related to a new "parallel tool call" feature. The regression specifically affected chat/completions streaming. We've implemented a fix and published a new prerelease build 0.66.0-alpha.7 if you'd like to validate that it addresses the problem you are seeing.

Checked with alpha.7, it seems we are back to original error:

2025-12-05T19:43:47.940208Z TRACE codex_api::sse::chat: SSE event: {"error":{"message":"litellm.BadRequestError: litellm.ContentPolicyViolationError: litellm.ContentPolicyViolationError: AzureException - 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_qNkcsS3iGORiq2AIMUrbRqvS

it seems we are back to original error

This is fixed in 0.66.0-alpha.11. I confirmed that it's working with the litellm proxy.

> it seems we are back to original error This is fixed in 0.66.0-alpha.11. I confirmed that it's working with the litellm proxy.

I"m still running into this with alpha 11:

{"error":{"message":"litellm.BadRequestError: AzureException BadRequestError - Invalid 'messages[5].tool_calls[0].function.name': empty string. Expected a string with minimum length 1, but got an empty string instead.. Received Model Group=gpt-5.1\nAvailable Model Group Fallbacks=None","type":"invalid_request_error","param":"messages[5].tool_calls[0].function.name","code":"400"}}

@robinson96, can you share your repro steps? I'm not seeing this, but it's likely that my configuration or prompt differs from yours.

Checked against v0.66.0-alpha.11 still the same as in https://github.com/openai/codex/pull/7038#issuecomment-3561310507

@jxy, can you share your repro steps? Does this occur only with certain models? If so, which one(s)? I'm testing with OpenAI models (both cloud-based and local gpt-oss models), and I'm not seeing the problem.

@robinson96, can you share your repro steps? I'm not seeing this, but it's likely that my configuration or prompt differs from yours.

Just went to reproduce again, and in it seems to be working now. I suspect my vscode extension still had a running process with the old executable in memory depsite having overrwritten it. Will be sure to respond again if there are more issues.

Instead of following the comment: https://github.com/openai/codex/pull/7038#issuecomment-3561310507
you may also follow the following:

1. get the latest build:

curl -LO https://github.com/openai/codex/releases/download/rust-v0.66.0-alpha.11/codex-aarch64-apple-darwin.zst
zstd -d codex-aarch64-apple-darwin.zst
chmod +x codex-aarch64-apple-darwin

1. save the following as a file, call it tcodex

#!/bin/sh

serv(){
{
cat <<'EOF'
HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{"role":"assistant","content":""},"finish_reason":null}]}

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{"content":"ASSISTANT MESSAGE HERE"},"finish_reason":null}]}

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{"content":null,"tool_calls":[{"index":0,"id":"call_testid","type":"function","function":{"name":"shell","arguments":""}}]},"finish_reason":null}]}

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{"tool_calls":[{"index":0,"function":{"arguments":"{\"command\":[\"bash\",\"-lc\",\"uname\"],\"timeout_ms\":120000,\"workdir\":\"/tmp\"}"}}]},"finish_reason":null}]}

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{},"finish_reason":"tool_calls"}]}

data: [DONE]
EOF
} | nc -l 8888 | sed '/^[^{]/d' | jq '.messages[2:]'
{
cat <<'EOF'
HTTP/1.1 200 OK
Content-Type: text/event-stream

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{"role":"assistant","content":""},"finish_reason":null}]}

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{"content":"CHECK WHAT I RECEIVED"},"finish_reason":null}]}

data: {"id":"chatcmpl-testid","object":"chat.completion.chunk","created":1763690000,"model":"gpt-test","choices":[{"index":0,"delta":{},"finish_reason":"stop"}]}

data: [DONE]
EOF
} | nc -l 8888 | sed '/^[^{]/d' | jq '.messages[2:]'
}

code(){
	codex-aarch64-apple-darwin \
	-c 'profiles.test.model_provider="test"' \
	-c 'model_providers.test.name="test"' \
	-c 'model_providers.test.base_url="http://localhost:8888/v1"' \
	-p test --full-auto \
	'A quick test.'
}

serv > /tmp/o.codex.json 2>&1 &
code
wait
cat /tmp/o.codex.json
rm /tmp/o.codex.json

1. run the file

./tcodex

1. press control-C to exit codex
2. observe the following:

╭──────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.66.0-alpha.11)                   │
│                                                      │
│ model:     gpt-5.1-codex-max high   /model to change │
│ directory: ~/tmp                                     │
╰──────────────────────────────────────────────────────╯

  Tip: You can run any shell commands from codex using ! (e.g. !ls)


› A quick test.


• ASSISTANT MESSAGE HERE

• Ran uname
  └ Darwin

─ Worked for 0s ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

• CHECK WHAT I RECEIVED
[
  {
    "role": "user",
    "content": "A quick test."
  }
]
[
  {
    "role": "user",
    "content": "A quick test."
  },
  {
    "role": "assistant",
    "content": null,
    "tool_calls": [
      {
        "id": "call_testid",
        "type": "function",
        "function": {
          "name": "shell",
          "arguments": "{\"command\":[\"bash\",\"-lc\",\"uname\"],\"timeout_ms\":120000,\"workdir\":\"/tmp\"}"
        }
      }
    ]
  },
  {
    "role": "assistant",
    "content": "ASSISTANT MESSAGE HERE"
  },
  {
    "role": "tool",
    "tool_call_id": "call_testid",
    "content": "Exit code: 0\nWall time: 0 seconds\nOutput:\nDarwin\n"
  }
]

@jxy, is there a real-world use case that's failing for you?

@etraut-openai yes

@jxy, can you explain the use case? Without those details, it difficult to evaluate user impact and determine whether it's something we'd like to prioritize.

Just tried with alpha.11 and I'm still getting:

2025-12-08T20:31:16.113560Z TRACE codex_api::sse::chat: SSE event: {"error":{"message":"litellm.BadRequestError: litellm.ContentPolicyViolationError: litellm.ContentPolicyViolationError: AzureException - 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_yO02NSPZHQJROWlTT1dOJ6Tt

@etraut-openai no. more detail is unnecessary.

We've published version 0.66.0 of the codex CLI. We think this addresses the bug report that kicked off this thread. It also addresses several other regressions related to the chat/completions API. Thanks to everyone on this thread for your help and patience as we worked through these issues.

We're announcing today that we plan to deprecate support for the chat/completions API in Codex and eventually remove support completely. For details, please refer to this discussion thread, which provides the rationale and timeline.

I'm going to close this issue since the OP's issue has been addressed. If you are seeing other problems with chat/completions handling in 0.66.0 that you would like us to look at, please open a new issue and provide details about your use case. As explained in our announcement, during the deprecation period we will triage bugs in this area based on user impact.

Not sure how this can be closed as 'completed' when it results in literally the same error as the OP? Should we open a bug with the same description?

2025-12-09T17:59:15.978003Z TRACE codex_api::sse::chat: SSE event: {"error":{"message":"litellm.BadRequestError: litellm.ContentPolicyViolationError: litellm.ContentPolicyViolationError: AzureException - 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_Ztlu3pWJ5Gkxqq36r

Anyways, I kind of understand that you want to move away from chat completions, as this was announced a while ago.
Guess it's back to using other harnesses for now 🫤

FYI for people watching this issue, 0.66.0 didn't resolve the issue.

• I’ll scan the repo and read the issue document to ground the redesign.

• Updated Plan
  └ □ Scan repo structure and tech stack
    □ Read project issues document
    □ Outline data model and boundaries
    □ Document proposal in markdown

■ {"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_qpOrCli47OR5sOcL8PLiguZP","param":"messages.[4].role","type":"invalid_request_error"}}

yes the issue still exist

getting this

■ {"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_qpOrCli47OR5sOcL8PLiguZP","param":"messages.[4].role","type":"invalid_request_error"}}

Just wanted to share I am also experiencing the same issue in the latest version (0.69)

error: 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_7oHxG0j6XGuv5DFukd1tDEQf","type":"invalid_request_error","param":"messages.[16].role","code":null}

If you are seeing other problems with chat/completions handling that you would like us to look at, please open a new issue and provide details about your use case. As explained in our announcement, during the deprecation period we will triage bugs in this area based on user impact.

I'm going to lock this issue to prevent additional posts.