Codex VS Code extension intermittently aborts Responses streaming (Bad Request, response.failed) even for simple prompts
What version of the IDE extension are you using?
26.324.21329
What subscription do you have?
Azure Provider
Which IDE are you using?
VS Code
What platform is your computer?
Edition Windows 11 Pro Version 22H2 Installed on 4/23/2024 OS build 22621.4317 Serial number 5CG408345R Experience Windows Feature Experience Pack 1000.22700.1041.0
What issue are you seeing?
When using the Codex VS Code extension with the Responses API, requests intermittently fail with “Bad Request” and streaming errors such as:
stream disconnected before completion: response.failed event received
This can happen even for very simple prompts like “hi”, especially on the first message of a new chat.
The same Responses API request (same model, same key, same prompt) works reliably in Postman, which suggests the issue is specific to the Codex extension’s request / streaming handling rather than the backend API.
What steps can reproduce the bug?
- Open a new chat in Codex.
- Send a simple prompt:
hi
- Codex UI immediately shows “Bad Request”.
- No response text is streamed.
- Provider logs show the request marked as stream completion failed.
- Sending the same prompt again (hi) sometimes succeeds, sometimes fails again.
- During longer conversations, similar failures can also appear mid‑chat with:
stream disconnected before completion: response.failed event received
What is the expected behavior?
- Simple prompts (e.g. “hi”) should never fail
- First message in a new chat should stream reliably
- Extension should not abort valid Responses streams
- Errors in optional/internal features should not cause request failure
Additional information
Observed Extension Logs (First Request Failure)
When the first request fails, the VS Code extension logs consistently show the following error:
Error fetching
errorMessage="local-environments is not supported in the extension"
errorName=Error
...
url=vscode://codex/local-environments
This error appears before the response fails.
Note: Warnings such as Received broadcast but no handler is configured can be seen both in successful and failed runs, so they may be incidental rather than the direct cause.
***
Provider / Backend Observations
From Azure / APIM logs:
- Failed requests are marked with:
isStreamCompletion = Failedcompletion_tokens = 0- No partial completion is recorded.
- The request itself is accepted (no request validation error).
***
Control Test (Important)
✅ Postman (Same Request)
- Same Responses API
- Same model
- Same API key
- Same prompt (
hi)
Result:
- ✅ Always succeeds
- ✅ Response returned normally
- ✅ No streaming failure
❌ Codex VS Code Extension
Result:
- ❌ Intermittent “Bad Request”
- ❌
response.failed - ❌ No completion tokens
- ❌ Unreliable streaming behavior
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
You mentioned that you're using an Azure endpoint. Have you reported this issue to the Azure folks? If not, please do so. Otherwise they will not be aware of the issue.
@etraut-openai
Hi, thanks for the response.
I don’t think this is an Azure-side issue. The same Azure endpoint, model, and Responses API work correctly when used from Postman and from other VS Code extensions such as Cline and GitHub Copilot.
The problem only occurs in the Codex (VS Code extension, CLI, APP). Specifically, the first request in a new chat frequently fails with “Bad Request,” and the stream is aborted. Resending the same message sometimes works, without any change to the endpoint or request.
Because this behavior is isolated to Codex and is not reproducible with the same endpoint elsewhere, it seems likely to be a Codex-side bug in how Responses streaming is initialized or handled.
@etraut-openai
Increasing the “maximum tokens per minute” limit greatly improved stability for me.
With a low limit (~250k), Codex frequently fails with response.failed. After raising it to ~9M, streaming is much more stable.
The only remaining issue is that the first request in a new chat still returns “Bad Request”, but retrying usually works.
I found that the Bad Request error on the first chat only occurs when there is a Git repository in the working project. When the project is not initialized as a Git repo, I don’t see this error.