›_ Codex Issues
Codex Issues / #14695

Azure Responses API: Bad Request when Codex sends tool output (shell_tool). function_call_output expects string, Codex appears to send object

Resolved 💬 4 comments Opened Mar 14, 2026 by doctor-sukha Closed Mar 16, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of the IDE extension are you using?

v26.311.21342

What subscription do you have?

Azure OpenAI / no OpenAI ChatGPT plan

Which IDE are you using?

VS Code

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

  • When using Codex v0.114.0 or the VS Code Codex extension with Azure OpenAI (Responses API), normal chat works but any tool execution (shell_tool / exec_command) results in “Bad Request”. However, downgrading the VS Code Codex extension to v0.4.69 makes the issue disappear.
  • Futhermore, disabling shell tools avoids the error. Azure accepts tool calls and tool outputs when the output is a string, but returns 400 if the output is an object.

What steps can reproduce the bug?

  1. codex exec "List files in this repo."
  2. Observe "Bad Request" after tool call attempt.

What is the expected behavior?

Tool call succeeds, and model returns output.

Additional information

Environment

  • Codex version: 0.114.0
  • VS Code Codex extension: 0.4.69 fixes it; newer versions (v26.311.21342) reproduce the issue
  • OS: macOS
  • Provider: Azure OpenAI (Responses API)
  • Model/deployment: gpt-5.2-codex
  • base_url: https://<resource_name>.cognitiveservices.azure.com/openai/v1
  • wire_api: responses
  • model_reasoning_effort: medium

Additional Evidence (Azure curl test)

Azure accepts function_call_output when output is string:

POST /responses
{
"model": "gpt-5.2-codex",
"previous_response_id": "<RESP_ID>",
"input": [{
"type": "function_call_output",
"call_id": "<CALL_ID>",
"output": "{"files":["a.txt","b.txt"]}"
}]
}
=> 200 OK

Azure rejects output object:

POST /responses
{
"model": "gpt-5.2-codex",
"previous_response_id": "<RESP_ID>",
"input": [{
"type": "function_call_output",
"call_id": "<CALL_ID>",
"output": { "stdout": "a\nb\n", "stderr": "", "exit_code": 0 }
}]
}
=> 400 invalid_request_error: Invalid type for input[0].output (expected string or array of objects)

Azure also rejects type "tool_output":

=> 400 invalid_request_error: Invalid value 'tool_output' (supported includes function_call_output)

Logs (Codex)

In codex-tui.log:

  • Tool call logged: ToolCall: exec_command {"cmd":"ls"}
  • Immediately after: Turn error: Bad Request

Hypothesis

Codex may be sending tool output in a structured object format that Azure Responses API rejects (expects a string or array of objects). This causes 400 on tool output submission.

View original on GitHub ↗

4 Comments

etraut-openai contributor · 5 months ago

Have you reported this issue to the Azure team? If not, please do so. Otherwise they won't be aware of the problem.

Azure hosts OpenAI models, and they use the same endpoint code as OpenAI. However, it often takes then a few weeks to integrate recent changes (bug fixes, enhancements) from OpenAI unless they hear from customers that something is broken. This is likely one of those cases. So it will probably clear up automatically in a couple of weeks, or you could report it to the Azure team and maybe get it fixed sooner.

doctor-sukha · 5 months ago

Thank you for the guidance. I’ll reach out to the Azure team about this.
@etraut-openai

doctor-sukha · 5 months ago

Additonal information

The Azure team has not replied to my report yet, but I noticed a few additional points.

  1. I cannot reproduce this issue on another MacBook or on a Windows laptop, even under the same conditions (same IDE extension version, ~/.codex/config.toml, and the same deployment created via Microsoft Foundry). This suggests that the issue may be device or environment specific.
  2. It does not appear that the file read operation itself is failing. The CLI successfully reads the file locally (the Explored → Read ... step completes), and the subsequent request seems to be sent to Azure. However, the request eventually results in a Bad Request error. This suggests that the failure likely occurs during request construction or during transmission to the Azure Responses API, rather than during the local file access step.
>_ OpenAI Codex (v0.114.0)

model:     gpt-5.3-codex medium
directory: ~/project/proj-ai-assisted

› summary backend/docs/ai-assisted-document.md

■ Bad Request

› summary backend/docs/ai-assisted-document.md

• I’ll read backend/docs/ai-assisted-document.md and give you a concise summary of its key points.

• Explored
  └ Read ai-assisted-document.md

■ Bad Request
2026-03-15T20:38:51.771146Z  INFO session_loop{thread_id=019cf338-08db-75d2-a3f7-5fba5cb1e99e}:submission_dispatch{submission.id=019cf339-1a79-7ed2-b4d2-baaf23d2c649}: codex_core::codex: new

2026-03-15T20:38:55.033825Z  INFO session_loop{thread_id=019cf338-08db-75d2-a3f7-5fba5cb1e99e}:submission_dispatch{submission.id=019cf339-1a79-7ed2-b4d2-ba99df9faf2e}:turn{
    thread.id=019cf338-08db-75d2-a3f7-5fba5cb1e99e
    turn.id=019cf339-1a79-7ed2-b4d2-ba99df9faf2e
    model=gpt-5.3-codex
}: codex_core::stream_events_utils: ToolCall: exec_command {"cmd":"sed -n '1,260p' backend/docs/ai-assisted-document.md"}

2026-03-15T20:38:56.228999Z  INFO session_loop{thread_id=019cf338-08db-75d2-a3f7-5fba5cb1e99e}:submission_dispatch{submission.id=019cf339-1a79-7ed2-b4d2-ba99df9faf2e}:turn{
    thread.id=019cf338-08db-75d2-a3f7-5fba5cb1e99e
    turn.id=019cf339-1a79-7ed2-b4d2-ba99df9faf2e
    model=gpt-5.3-codex
}: codex_core::codex: Turn error: Bad Request

For now, I am still able to use Codex by downgrading the IDE extension to v0.4.69, where the issue does not occur. However, I would strongly prefer to use the latest version of the extension, so I would greatly appreciate any help in identifying the root cause of this issue. @etraut-openai

doctor-sukha · 5 months ago

I think I’ve figured out what’s causing this issue.
It’s one of the following:

  1. The project’s absolute path contained Japanese characters. For example, “ドキュメント”, which means “document”.
  2. Another possibility is that the path was located on OneDrive. When I changed it to my local storage, it worked perfectly. (Users/<username>/Documents/project)

I hope this information is helpful to others who are struggling with “Bad Request” errors.