Codex Cloud task list shows Failed while task details show Working and CLI reports PENDING

What issue are you seeing?

Codex Cloud exposes contradictory status for the same task, making it difficult to decide whether to wait, recover work, or retry.

Observed on September 17, 2026, with ChatGPT Pro:

• The Cloud task list at chatgpt.com/codex/cloud shows Failed in red for the task (confirmed in a user screenshot).
• The task detail page, inspected after reloading, still shows Working on your task and a Cancel task button.
• A subsequent supported CLI status request continues to return:

$ codex cloud status <same-task-id>
[PENDING] <task title redacted>
<environment name redacted>  •  6h ago
no diff

The command exits with status 1. An earlier codex cloud diff <same-task-id> request returned:

Error: No diff available for task <same-task-id>; it may still be running.

The UI and CLI observations were made during the same troubleshooting session, not as one atomic server snapshot. Nevertheless, the CLI continued reporting PENDING after the Failed screenshot was supplied. The task detail page had also required a fresh load to expose newer activity. I cannot use its spinner as proof that the worker is alive.

What steps can reproduce the bug?

This is an observed private-task incident, not yet a public minimal reproducer:

1. Run a multi-turn development task in Codex Cloud.
2. Let the task perform implementation and build/quality checks.
3. When the Cloud task list shows Failed, open/reload that same task's detail page.
4. Compare the list status, detail status, and codex cloud status <task-id>.

In this incident the list showed Failed, the detail page showed Working on your task/Cancel task, and the CLI reported PENDING with no diff.

What is the expected behavior?

• All task surfaces should converge on the same current attempt status.
• If Failed applies to one attempt and Working/PENDING applies to another, expose attempt identifiers and timestamps so that distinction is understandable.
• A terminal failure should expose its reason and last successful checkpoint, rather than leave a working indicator and ambiguous Cancel action.
• Clearly state which recovery/export options are available for edited files after failure, before the user retries or cancels.

Additional information

• CLI: codex-cli 0.151.0 on macOS. Main affected surface: Codex Cloud/Web.
• The runtime logs showed real source edits and build attempts. One Kotlin compilation failed with Unresolved reference 'LocalDate'; a later attempt reported java.lang.OutOfMemoryError: GC overhead limit exceeded and Not enough memory to run compilation. Later visible output included frontend formatting.
• Those are command failures inside the task. We have not established that they caused the Cloud task's terminal Failed state.
• The environment uses a private wrapper repository with a separately cloned nested application repository. We do not assume the absence of a top-level task diff means no application edits occurred.
• A usage-nearing-limit banner was visible, but there is no verified quota-exhaustion error tying it to the failure.
• Separately, the desktop client logged invalid thread id while trying to read the Cloud task through a local thread path. That does not explain away the Failed status in the Cloud website itself.
• No retry or cancellation was performed as part of this status diagnosis.

Related: #43561 (Failed after successful final response) and #45264 (Cloud observability). This report is specifically about conflicting status across the Cloud task list, task detail, and CLI; we have not confirmed the same cause as either report.

Private task/environment identifiers and screenshots can be supplied through a private support channel. Application source, internal repository names/hosts, credentials, and business requirements are omitted from this public report.

Start by comparing the Cloud task list, the reloaded task detail page, and codex cloud status <task-id> for the same task, using the reported PENDING and Failed observations. Trace how each surface obtains and labels attempt status; done means a terminal failure, an active attempt, or multiple attempts are presented consistently with a reason, identifiers, and timestamps.