›_ Codex Issues
Codex Issues / #39960

This past weeks performance has been deplorable

Open 💬 3 comments Opened Aug 21, 2026 by BDookie02
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex Desktop App Bug Report

I’m experiencing a severe reliability regression in the Codex desktop app that has been ongoing for roughly the past week and became worse after updating the app within the last 1–2 days.

Environment:

Product: Codex desktop app / ChatGPT desktop app with Codex
Platform: Windows desktop
Plan: ChatGPT Pro
Approximate onset: about one week ago
Recent change: updated the desktop app within the last 1–2 days; behavior became noticeably worse afterward
Observed behavior:

I submit a normal, non-empty request, but the app sometimes freezes immediately or appears to stop registering the turn.
After force-closing and reopening the app, the submitted request may still not appear correctly. I’ve rebooted my desktop itself countless times as well.
I then sometimes see the error: “Failed to submit turn input. Empty input,” even though the input was not empty and I had entered one or more complete requests.
At times, submitted turns take a very long time to appear. After restarting the app, I can see that the request failed.
When a failed/stuck turn appears, attempting to steer or continue the conversation may also fail or become unresponsive.
Creating a branch conversation does not appear to reliably resolve the issue.
The desktop UI can freeze while the underlying Codex task appears to continue running. I have observed this because Voice could sometimes continue explaining what Codex was doing while the visible desktop app was frozen.
Even when the underlying task continues, processing becomes extremely slow and unreliable, and some instructions appear not to be processed at all.
This does not appear to correlate with project size. I have successfully worked on larger projects before, and I currently have other projects larger than the affected one.
The problem is not isolated to a single project; Codex desktop in general has behaved this way repeatedly over the past week.
The issue is disruptive enough that I have repeatedly had to force-close and reopen the app just to continue working.
Expected behavior:

Submitted text should register immediately and never be reported as empty when it contains content.
The desktop UI should remain responsive while Codex is running.
Restarting the app should not be required to make submitted turns appear or to recover normal interaction.
Steering and follow-up turns should work reliably after a task begins.
Actual impact:
The desktop app has become unreliable for normal development work. The freezing, missing/delayed turns, false “Empty input” errors, and repeated forced restarts are significantly interrupting active projects.

Please investigate this as a possible recent Windows desktop regression involving turn submission, UI state/sync, or desktop app responsiveness. I can provide screenshots, screen recordings, timestamps, app version information, and additional reproduction details if needed.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 6 days ago

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

  • #39727

Powered by Codex Action

Fireotics · 6 days ago

{"detail":"Bad Request"}

nos1609 · 33 minutes ago

Current-version false EmptyInput: non-empty composer text is rejected before remote transport

I reproduced the exact UI error from this issue on a current Windows Desktop build while working in a long-running SSH-backed task:

failed to submit turn input: EmptyInput

The composer contained a normal, non-empty text request.

Environment
  • Windows 11 ARM64
  • Codex Desktop: 26.825.4187.0
  • Desktop-bundled runtime: codex-cli 0.150.0-alpha.12.2
  • Remote Linux app-server: codex-cli 0.150.1
  • Target task: active, legacy history, readable persisted rollout
Transport evidence

I queried the remote app-server's structured log database immediately afterward:

  • total log records containing EmptyInput: 0;
  • no empty TurnInput reached the target task;
  • the task remained active and continued executing normally;
  • the state row and rollout remained intact;
  • a later submission from the same Desktop surface reached the server as a normal TurnInput containing non-empty text.

The remote server therefore did not produce this error. Desktop generated or surfaced EmptyInput before remote transport. This is consistent with a renderer/composer serialization race, especially when a task already has an active turn and the next message must become steer or queued input.

Expected behavior

When the composer visibly contains text, Desktop should serialize that exact content and either:

  1. send it as turn/start, turn/steer, or queued input according to task state; or
  2. preserve the draft and show a specific lifecycle/transport error.

Client-side validation must use the same structured input object that will be sent, not a stale or text-only projection that can be empty while the visible composer is not.

Actual behavior
  • visible non-empty input is rejected as EmptyInput;
  • no corresponding RPC reaches the remote app-server;
  • the error does not identify that it is client-side;
  • retrying can later submit normally, which makes delivery state ambiguous.

This also risks duplicate delivery: after a false rejection, the user cannot know whether the original text was queued locally, dropped, or safe to retry.

Suggested diagnostics and regression coverage
  • Log a privacy-safe content-shape summary at submit time: item count and input variant types, without text.
  • Correlate composer submit, client validation, and RPC dispatch with one request ID.
  • Test non-empty text while the target turn is active, including steer/queue transitions.
  • Test text plus mention/attachment/skill items and image-only input.
  • On validation failure, never clear the draft.
  • Distinguish client_empty_input from an app-server error in the UI and telemetry.

This appears to be the specific false-empty-input failure described in the issue, separate from the backend/UI progress desynchronization in #39727.