Regression: unclickable file-change approval permanently strands Codex Desktop task

Resolved 💬 1 comment Opened Jul 31, 2026 by brityonge Closed Jul 31, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What issue are you seeing?

Codex Desktop can display a file-change approval card whose controls no longer resolve the approval. Clicking the approval choice/submit control has no effective result, and the task remains permanently stuck in waitingOnApproval.

This occurred on three separate tasks on 2026-07-31. All three remain:

  • task state: active
  • task status: waitingOnApproval
  • latest item: fileChange
  • item status: inProgress

The persisted task rollouts end with a pending file-change tool call and no corresponding tool output/resolution. Switching tasks and restarting Codex Desktop did not restore or cancel the pending request.

Two affected tasks originated on an older core build and were resumed later. To rule out a stale pre-upgrade task as the sole cause, recovery was attempted in a newly created task using Codex core 0.146.0-alpha.9.2; that new task reproduced the same approval deadlock.

The requested changes were recovered and completed successfully in a separate task running without interactive approvals, so the patch contents and target files were not the cause.

This is a showstopper because one unresolvable approval permanently strands the task. There is no reliable visible Cancel/Decline/retry path after the UI enters this state.

Environment

  • Client surface: Codex Desktop on macOS
  • Workspace host: remote Linux/VPS
  • Current Codex core: 0.146.0-alpha.9.2
  • Affected turn policy: approval_policy=on-request, sandbox_mode=workspace-write
  • Approval type: file change / fileChange
  • Incident times (UTC): approximately 20:23, 20:24, and 20:37 on 2026-07-31
  • Desktop build number: not available from the remote task metadata

Private task IDs and workspace contents are intentionally omitted from this public report but can be provided privately to OpenAI if needed.

Steps to reproduce

The failure is intermittent, but the observed sequence was:

  1. Open or resume a Codex Desktop task connected to a remote Linux workspace.
  2. Run a turn with on-request approvals and workspace-write sandboxing.
  3. Let the turn request approval for a file change.
  4. The approval card appears in Desktop.
  5. Select an approval response and attempt to submit it.
  6. The task remains in waitingOnApproval; no resolution reaches the task.
  7. Switch to another task and back, or restart Desktop.
  8. The original task remains stranded on the same in-progress file-change item.

Expected behavior

Any approval choice should produce a terminal approval response, resolve the server request, complete/cancel the file-change item, and allow the task to continue.

If the client loses association with the pending request, Desktop should:

  • rehydrate the approval after reconnect/restart, or
  • expose an out-of-band Cancel/Decline action, and
  • automatically cancel orphaned approval requests after a bounded timeout.

Changing permission mode or restarting the client should not leave an old task permanently unusable.

Related reports

  • #10760 — exact prior symptom: approval selection highlights but cannot be submitted; OpenAI identified a UI deadlock involving approval requests and parallel tool calls and shipped a fix in February 2026.
  • #23875 — resumed/compacted Desktop tasks lose approval-review state.
  • #21839 — existing macOS Desktop tasks unexpectedly require approvals after restart/update.
  • #32538 — newer builds show repeated approval/apply-patch stalls and delayed resolution.

This appears to be either a regression of #10760 or a newer stale-request/resume variant in the same approval lifecycle.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 27 days ago

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

  • #36115

Powered by Codex Action