"Bad request" error

What version of Codex CLI is running?

0.94.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.2 xhigh

What platform is your computer?

Darwin 25.1.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Terminal.app

What issue are you seeing?

{"detail":"Bad Request"}

This continues to happen after 30+ minutes when I send a prompt. I have 39% context left. It's unrecoverable and generates the same error if I send "continue."

thread ID: 019c2394-2e58-7eb0-98e7-978424cb4745

What steps can reproduce the bug?

Seems specific to a larger project that requires a lot of reasoning to move forward. I haven't seen it in other sessions.

What is the expected behavior?

No response

Additional information

No response

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Constant "Bad Request" happening to me #10343

Powered by Codex Action

I understand the wish to not duplicate issues but I am having this issue and #10343 is closed. So here is my feedback on it. Current situation is hardly useable for longer tasks: #10343 (comment)

Update. Here is a good example:

Getting {"detail":"Bad Request"} on almost every single request/reply. What the hell is causing this? Codex is almost unusable because this error shows up so often.

@ryanc-cf

@ryanc-cf, please use /feedback to upload your logs and session details and post your thread ID here. That will allow us to investigate.

@etraut-openai

@etraut-openai See here, 3x in a row :/ #12477

@etraut-openai

@etraut-openai I've been seeing this error over and over, from the Codex app. I believe that it's related to having a big context several times "compressed", at some point, something breaks and it faces the bad request error very fast (even if not directly, like after a few messages.
If I start a new chat session, I don't see the problem for a long time

If you see this, please use the /feedback slash command to upload your logs and session details, then post the thread ID here.

@etraut-openai

here's one @etraut-openai 019c81c3-1821-73c3-9523-5a976caf5200

thread ID 019cb071-37bc-79c0-81e4-7020e72bbf0d

codex cli on ubuntu

019d2080-1aee-7db2-a066-ec3e4fb4cf94 on every request codex gui on MacOs

getting this error on gpt 5.4 and 5.5 on multiple agent chats
Thread id example: 019db8a5-9754-7c62-b0ab-9cf80011d1bf
Plan: pro x2
Mac OS, using the desktop codex app.
Seems like the agent thread gets corrupted, tried forking the thread to see if that helped but had the same error on every message or almost every message. It felt like usually after calling a bash read or some tool/mcp. But not sure sometimes it happened just responding.
Copying the thread id and continuing with the same model and config in a separate chat worked with no issues

getting{"detail":"Bad Request"} error in codex since today, breakig the /goal flow. gpt 5.5 high

Getting this again now in the latest Codex! Come on!!!!

I'm getting {"detail":"Bad Request"} every time I'm trying to make codex to work with e2e screenshot testing - looks like it chokes

this is happening to me too while working with multiple images (generatin/reading), the websocket keeps reconnecting, then fallsback to HTTPS, and then it errors with that bad request

UPDATE: 0.144.1 version was failing constantly, 0.145.0 now fails sometimes

Still reproducible on the latest Codex CLI 0.147.0.

Environment / repro details:

Codex CLI: 0.147.0 (upgraded from 0.146.0; upgrade did not fix it)
macOS, Apple Silicon
Model: gpt-5.6-sol
Long-running software-engineering session with many tool/command executions
Context was about 126K / 258K when the issue occurred, so the context window was not exhausted
/compact was run, but the problem persisted
Exiting and resuming the same session also did not fix it
The session has used /goal
The failure can recur repeatedly as:
■ {"detail":"Bad Request"}

I uploaded the affected session with /feedback as requested.

Thread ID: 019f804e-6921-7ca2-8299-24c3ba432134

This is particularly disruptive because abandoning the session is not a practical workaround for long-running coding tasks with substantial accumulated context. Please investigate the uploaded thread/session state; it may also help determine whether the trigger is related to long transcripts/tool outputs, resume state, /goal, or request serialization.

Update: I was able to recover the same affected thread without starting a new conversation, and the result strongly points to accumulated inline images in the rollout history as the trigger.

Affected thread (already uploaded via /feedback):
019f804e-6921-7ca2-8299-24c3ba432134

Environment:

Codex CLI 0.147.0
macOS / Apple Silicon
gpt-5.6-sol
long-running software-engineering thread

What I observed:

The problem started after a period of frequent image/screenshot use.
The rollout JSONL had grown to ~985 MB.
/compact, upgrading 0.146.0 -> 0.147.0, restarting, and resuming the same thread did not fix the repeated ■ {"detail":"Bad Request"} failures.

I inspected and repaired the local rollout while preserving the same thread ID and text/tool history:

removed 574 structured input_image entries
removed ~864.98 MiB of inline image payloads
removed 15 additional codex/toolSurface.screenshot.url inline screenshots (~5.71 MiB)
verified input_image count = 0
verified data:image/ count = 0
validated all JSONL records after the edit
rollout size dropped from ~985 MB to ~114 MB

After this image-only cleanup, I resumed the same thread and the repeated {"detail":"Bad Request"} problem stopped. No /new or replacement thread was required.

This is only a workaround, not a fix. It suggests that large numbers of inline base64 images can accumulate in replayable thread state and eventually make subsequent Responses requests fail with a generic 400. Codex should ideally externalize/cap/sanitize image payloads before they become durable replay history, and provide a repair path for already affected threads.

This appears closely related to #18629 (inline base64 tool images poisoning replayable thread state).

Still getting this error on GPT-5.6 Sol. Any update on this issue?

Getting this in ChatGPT Work on macOS as well. The entire Work run fails with {"detail":"Bad Request"} after running for a while, then the job stops and is marked as completed. This ruins unattended/overnight jobs because there is no retry or recovery.

Additional measured occurrence on Windows with OpenAI's ChatGPT-backed Codex Responses endpoint. This is recoverable by a later user turn in the same task, but interrupts unattended development.

Desktop package: OpenAI.Codex 26.901.6511.0 x64; bundled app-server 0.153.4.
Model: GPT-6 Astra. No custom provider or context/compaction override found.
Time: 2026-09-07 00:53:50 UTC.
POST https://chatgpt.com/backend-api/codex/responses returned HTTP 400, followed by {"detail":"Bad Request"}.
Request ID: 7856edd4-faf4-4696-9a62-f8c8e3913eca.
CF ray: a371bd13eb0ba4d3-MIA.
Prior context metadata: 84,080 usage tokens, auto-compaction scope limit 244,800, full context limit 258,400, full_context_window_limit_reached=false.
Failed request size: 4,901,395 bytes before compression /409,512 after. The preceding successful request was 4,894,198 /405,968 bytes.
Five preceding requests at 00:48–00:52 UTC returned 200. Later same-task requests at 00:56:38, 00:56:49 and 00:57:10 also returned 200 after a new user turn.
No actual root-thread compaction/truncation failure was found in retained logs.

The event followed a completed read-only CI-status tool operation; GitHub's build continued independently. No external write was being rejected. The logs provide no validation reason, so these measurements do not establish a payload ceiling, image cause or exhausted context. Related image/payload reports such as #41338 may describe another path to the same generic error.

Please correlate the request ID with the server-side rejection reason and expose an actionable error/recovery path. No request body, image, credentials, raw logs, project content or local filesystem path is included here. No permanent client-side repair is claimed.

I’m seeing what appears to be the same failure in Codex Desktop on macOS (Intel).

The affected task was a long-running, tool-heavy workflow with many browser/computer-use calls. A contextCompaction event occurred during the task, and the task initially continued successfully afterward. Later, every follow-up began returning:

{"detail":"Bad Request"}

I am seeing the same thing since lastnigh in codex and this morning.

Navigation Menu

Repository navigation

"Bad request" error #10571

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

"Bad request" error #10571

Description

What version of Codex CLI is running?

What subscription do you have?

Which model were you using?

What platform is your computer?

What terminal emulator and version are you using (if applicable)?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Feb 4, 2026

pardeike commented on Feb 10, 2026

pardeike commented on Feb 10, 2026

ryanc-cf commented on Feb 21, 2026

etraut-openai commented on Feb 21, 2026

ryanc-cf commented on Feb 21, 2026

ryanc-cf commented on Feb 21, 2026

BBARLOCCO commented on Feb 22, 2026

etraut-openai commented on Feb 22, 2026

BBARLOCCO commented on Feb 22, 2026

11 remaining items

ReidGarland commented on Mar 3, 2026

stefanwiele commented on Mar 26, 2026

juansalvatore commented on Apr 23, 2026

JustFly1984 commented on Jun 14, 2026

NellInc commented on Jul 14, 2026

JustFly1984 commented on Jul 14, 2026

madacol commented on Jul 28, 2026

JeremySun1224 commented on Aug 15, 2026

JeremySun1224 commented on Aug 15, 2026

yair-zenity commented on Aug 31, 2026

HonkCY commented on Sep 7, 2026

dominicrf commented on Sep 7, 2026

manuelpgs commented on Sep 18, 2026

yepher commented on Sep 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions