[macOS] Repeated Bad Request aborts desktop turns after successful commands and on simple follow-ups #44408

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Sep 10, 2026
2. github-actions commented on Sep 10, 2026

   

   github-actionsBot

   on Sep 10, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows desktop: Bad Request after successful local tool calls #43711

   Powered by Codex Action
3. jimmycarp966 commented on Sep 11, 2026

   

   jimmycarp966

   on Sep 11, 2026

   Author

   More actions

   This is still happening. A second long-running desktop task has now become unusable with the same generic Bad Request, leaving authorized work unfinished and even immediate text-only follow-ups unanswered.

   Current environment, rechecked from the installed bundle and OS metadata:

   • App bundle identifier: com.openai.codex; current version 26.903.71938 (build 8576). The original report listed 26.903.61454 (8378). This is the version installed at this follow-up, not a claim that the exact build active at every historical failure was recorded.
   • macOS 26.6.2 (25G83), Darwin 25.6.0, Apple Silicon arm64.
   • ChatGPT Pro; affected session metadata records Codex Desktop, CLI/runtime version 0.153.4.
   • All four newly affected turn contexts record gpt-6-astra, reasoning effort high, default collaboration mode; the earlier issue recorded effort low.

   New affected session: 01a08989-3438-7662-a2f3-040937b81fc4. This was the separate task originally used to file these reports, and it subsequently ran normally for many turns before encountering the same failure.

   Four consecutive failed turns, with completion timestamps in UTC:

   Completion	Turn ID	Recorded behavior
   2026-09-11 00:10:36.535	01a08da4-6069-71e2-ae0c-43def9c0c44b	Aborted after substantial work and progress messages.
   2026-09-11 01:06:43.692	01a08df7-d374-79e1-8e4c-29a0f17af289	A subsequent attempt continued working for 579,522 ms, then failed without a final answer.
   2026-09-11 01:07:09.701	01a08e01-0dac-7701-852c-7abcf695ea18	Plain-text “que paso ahora?” follow-up failed in 835 ms, without an assistant reply or tool call.
   2026-09-11 01:07:36.658	01a08e01-7746-7d02-8f61-d46754c0750c	Plain-text “???” follow-up failed in 764 ms, without an assistant reply or tool call.

   All four persisted completion events contain:

   {"last_agent_message":null,"error":{"message":"{\"detail\":\"Bad Request\"}","codex_error_info":"other"}}

   For the 01:06:43 failure, three image-view items completed at 01:06:42.889–42.892 and a local command completed with exit code 0 at 01:06:42.977, approximately 715 ms before the turn aborted. An earlier local script assertion had failed, but subsequent commands completed successfully and the assistant continued before the separate generic request failure. The record does not establish that the script, image viewing, or any MCP caused the abort.

   The last available token-count event at 01:06:43.068 reports 77,855 input tokens / 258,400 context window (~30%). This is the last recorded successful usage, not the size of the rejected request or proof that a context limit was or was not involved. The session includes 11 compaction records; no causal relationship has been established.

   A fresh read of this task returns systemError and the same four failed turn IDs, with additionalDetails: null. The original session also contains one additional persisted failure at 2026-09-10 04:44:55.393 UTC, turn 01a089a1-e76d-7a01-9fa4-26bcab2b0caa, beyond the 13 initially reported.

   I had to move to another task again to reconstruct progress and continue. The history-retrieval issue is also still observable; details are being added to #44409. No numeric HTTP status, failing endpoint, backend request ID, or root cause is available in these completion errors. Please use the session/turn IDs and UTC timestamps for server-side correlation. Full private transcripts, credentials, configuration values, and media URLs are intentionally omitted.
4. jimmycarp966 commented on Sep 11, 2026

   

   jimmycarp966

   on Sep 11, 2026

   Author

   More actions

   Another recurrence: the replacement task used to recover the previous broken conversation has now also failed. This is the third affected session documented in this issue. Moving to a new task temporarily permits progress, but has not provided a durable recovery. Reconstructing context repeatedly is making normal work impractical.

   Newly affected session and environment

   • Session: 01a08e01-a84b-76a1-82c3-4fc345a219c2.
   • Failed turn: 01a08e18-57ed-70e3-9ece-6fb31dfaa096.
   • Current installed bundle, rechecked: com.openai.codex, 26.903.71938 (8576). This is the installed version at investigation time, not independent proof of the build active at every historical event.
   • macOS 26.6.2, Apple Silicon arm64; ChatGPT Pro confirmed in the session's usage metadata.
   • Session originator: Codex Desktop; runtime/CLI version 0.153.4, source metadata vscode, provider openai.
   • Failing turn: gpt-6-astra, reasoning effort medium, default collaboration mode. Earlier occurrences in this issue used low and high.
   • The task was doing media production using local commands, browser automation, image inspection, and DaVinci Resolve MCP. Authorized work remained unfinished when the turn aborted.

   Exact timeline (UTC, 2026-09-11)

   Timestamp	Persisted evidence
   01:07:48.452	Replacement session created to recover the preceding failed task.
   01:08:15–01:31:26	Four turns completed successfully, including recovery work and publishing the earlier issue updates.
   01:32:35.217	New working turn started after a plain-text instruction to proceed.
   01:58:01.696	DaVinci MCP run_script completed successfully; three frame exports each returned ok: true.
   01:58:06.495 / .530 / .562	Three local image-view completion events.
   01:58:06.656	Tool output persisted with three PNG image entries.
   01:58:06.692	Last available token-count event.
   01:58:21.178	Turn aborted with the same generic Bad Request, no final assistant answer.

   Duration: 1,545,938 ms (25 minutes 45.938 seconds). The failure occurred 14.522 seconds after the last persisted image tool output, rather than being reported as a failed image-view tool call. Local time of failure was September 10, 22:58:21 ART (UTC−03:00).

   Exact completion error excerpt:

   {
     "turn_id": "01a08e18-57ed-70e3-9ece-6fb31dfaa096",
     "last_agent_message": null,
     "error": {
       "message": "{\"detail\":\"Bad Request\"}",
       "codex_error_info": "other"
     },
     "duration_ms": 1545938
   }

   Request/context clues for investigation

   • Last recorded successful usage: 215,558 input tokens, 215,168 cached input tokens, 63 output tokens, reported model context window 258,400 (~83.4% input/window). This is not the measured size of the rejected request.
   • A near-exhausted-context notice was recorded immediately after the image output. The session contains one compaction record at 01:29:04.493 UTC, before the failed turn. This is temporal evidence only; it does not establish a context-overflow or compaction cause.
   • The final persisted tool output contains three 1920×1080 PNG entries, 6,231,977 decoded bytes each (18,695,931 bytes total before base64 encoding). This describes the local record, not a network capture or proof of the payload actually submitted to the backend. Please investigate request validation/payload handling alongside context handling.
   • Last successful response identifier: resp_044da36a91e02f54016aa3602a18c487d29e88032c06bfbf88. This is a correlation clue for the preceding successful response, not an ID for the rejected request.
   • Earlier individual browser/tool/script errors were followed by successful work; no evidence establishes one of them as the cause of the final turn abort. A separate external media-service credit rejection occurred earlier and the assistant continued editing afterward; it should not be conflated with this Codex completion error.
   • Last Codex usage metadata shows 52% used in the reported window and rate_limit_reached_type: null; it does not record a Codex rate-limit error. This does not rule out an unreported backend limit.

   Cross-session recurrence and recovery impact

   1. 01a0820c-21a3-7381-9817-5dd5952beede: original repeated failures in the issue body and previous follow-up.
   2. 01a08989-3438-7662-a2f3-040937b81fc4: replacement/reporting task later failed, including immediate text-only follow-ups (previous comment).
   3. 01a08e01-a84b-76a1-82c3-4fc345a219c2: next recovery task worked, published the preceding reports, then failed again as documented above.

   The user now has to open yet another task to report this and recover progress. Substantial tool work can succeed, yet the conversation stops without a useful explanation or completion handoff. Please investigate this as a recurring work-blocking failure, provide an actionable error/recovery path, and correlate the session/turn IDs and UTC timestamps server-side.

   For comparison with #44409: a fresh task-reader request for this third session returned all five turn headers with nonempty items, including the failed turn, and systemError / additionalDetails: null. The newest-page response reported hasMore: false. Thus this new occurrence confirms Bad Request, but does not newly reproduce the stale/empty-history retrieval symptom in this particular session. No GUI history-loss claim is added here.

   I reviewed the full available five-turn conversation and its persisted diagnostic record. No numeric HTTP status, rejected-request ID, failing endpoint, or root cause is exposed by the completion error. Only selected diagnostic metadata is shared; full transcripts, images, prompts, client/project content, personal paths, account identifiers, credentials, and signed media URLs are omitted.