"Bad request" error

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

• #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: https://github.com/openai/codex/issues/10343#issuecomment-3877198157

Update. Here is a good example:

<img width="854" height="685" alt="Image" src="https://github.com/user-attachments/assets/c09f33f3-9fc4-4699-94e3-506319cead15" />

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, please use /feedback to upload your logs and session details and post your thread ID here. That will allow us to investigate.

<img width="3790" height="1615" alt="Image" src="https://github.com/user-attachments/assets/529396b9-45a1-4e4b-867a-cd7fe749ed40" />

@etraut-openai See here, 3x in a row :/ https://github.com/openai/codex/issues/12477

@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.

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

@etraut-openai I think BBARLOCCO is right, I tried making a new session and it didnt work for me. But I do recall it compacting the session lots of times and then eventually these errors started showing up. The fix for me was to actually delete ~/.codex completely and start over. For some reason starting a new session wouldnt fix it for me. But I do suspect it's multiple compactions that are the problem child. It got to a point where compacting would result in about 37% free when it should have been closer to 90-98% I think. So it's summary was super long. Perhaps the fix is to put a limit on how long the summary can be?

Thanks @ryanc-cf. I think we have the details we need to identify the specific failures in our back-end logs. We're exploring a couple of working theories and trying to root cause.

Haven't tried clearing the folder yet, but I'm having the same issue. Also have a very long summary that's taking up around 75% of the context window.

It appears to be correlated with unusually long sessions and user prompts.

My session is not particularly long and neither are the prompts

019c8bf9-8ec0-7b12-9ded-e32ecaab5668

@kalleh, the rollout you uploaded is very long. It's over 100MB and contains well over 10,000 items.

@etraut-openai I was invited to test the new Codex for Windows app. After installing it, I started to receive {"detail":"Bad Request"} errors on each session, generally within 10 minutes into execution. The errors have been occurring in both the new Codex for Windows app and the Codex VS Code extension. I thought it might be a conflict between the two, so I uninstalled both as well as VS Code. I deleted every file I could find related to Codex or VS Code from my pc. I reinstalled VS Code and the Codex extension. The error has not gone away.

019ca095-6396-7082-8d4b-aa83afcf1be6

--
UPDATE: In order to get moving again, I switched to WSL. It appears to have eliminated the issues. On the Codex Extension in VS Code, I clicked the gear icon in the upper right corner, then "Windows Settings" > "Run in WSL". This is not a direct "fix" per-se but seems to have gotten Codex working again for me.

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).